NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>From: James Murakami <address@hidden> >Organization: UCLA >Keywords: 200212032325.gB3NPG416485 James, >The version of perl on the machine Sundog is v5.8.0 for i386-linux. This is the same as on the other RH 8.0 system that I have access to. >I created a symbolic link for the data directory so that the original >$data_path = "$ldmhome/data" applies in the default ldmadmin file. Nothing >changed. I even re-ran the scriptconfig program. OK. I figured it was worth a try. >It's funny that when I tried deleting the ldm.pq file using the command >"ldmadmin delqueue", I got a similar "split loop" error (line 478). The procedure that does the delqueue action uses the same 'split' logic as the start action, so the repeat of the error is expected. >The "mkqueue" works without complaint. The mkqueue action does not use that logic construct. By any chance, do you have an alias for 'ls' in your user environment? If so, I would either unalias ls before running ldmadmin or try editing ldmadmin and changing all occurrances of: ( @QUEUES ) = split( "[ \t\n]+", `ls $pq_path` ); to: ( @QUEUES ) = split( "[ \t\n]+", `/bin/ls $pq_path` ); If this also fails, you could comment out the offending lines so you can, at least, get going. I checked the LDM inquiry archives for this problem, and see that one other RH 8 user ran into it. The problem was apparently never resolved, so we are breaking new ground here. >I'm open to suggestions that you or others at Unidata offer. Three of us discussed this problem this evening. The alias of the ls command was the only thing we could think of that might cause this problem. Tom