Hmm, this is a weird one -- I ran a batch script that I asked about a few
months ago, and it initially worked to list the files in my directory. I
fooled around with the bash script a bit and it appeared to freeze my PC
(cygwin, latest cvs of grass 6.1). Once I rebooted the program, it appears
to be hanging on g.mlist --> I suspect (but may be wrong) that something in
the location file may have gotten a bit screwed up, since a different
location works fine with g.mlist (and my batch script). Is there a way to
repair a location file, or is there some other reason why this would be
freezing on me?
--j
--
Jonathan A. Greenberg, PhD
NRC Research Associate
NASA Ames Research Center
MS 242-4
Moffett Field, CA 94035-1000
650-604-5896
AIM: jgrn307
MSN: jgrn307@hotmail.com
Jonathan Greenberg wrote on 06/15/2006 05:38 AM:
Hmm, this is a weird one -- I ran a batch script that I asked about a few
months ago, and it initially worked to list the files in my directory. I
fooled around with the bash script a bit and it appeared to freeze my PC
(cygwin, latest cvs of grass 6.1). Once I rebooted the program, it appears
to be hanging on g.mlist --> I suspect (but may be wrong) that something in
the location file may have gotten a bit screwed up, since a different
location works fine with g.mlist (and my batch script). Is there a way to
repair a location file, or is there some other reason why this would be
freezing on me?
Jonathan,
you may try to check with a small subset. Since g.list is a script, it
can be very slow
if many maps are in the mapset/mapset search path.
Example: I am processing daily MODIS data and have to wait minutes (!)
to get
a selection done because I have > 10000 maps in the search path.
You could check if the CPU is sleeping. And/or use strace or lsof -p PID to
check what the job is doing.
But does it really *freeze* the PC or doesn't it output anything in a
reasonable time?
I can't imagine that a script can crash a PC.
Markus