Maris Nartiss wrote: > Alltough Glynns suggestion about redirecting GRASS error messages ALSO > to some error.log file would be a good idea as this file could be a > must for (crash) bug reporting. Only as a non-programmer I see some > difficulties: > 1) How multiple processes (modules) can append data to that file in sane way; > 2) When enable such functionality? I.E. g.env set=ERRLOG=true > 3) What else needs to be written to such file? I.E. command history, > arch, GRASS version...
I wasn't talking about writing to a "log" file, but a temporary file which would be used for a single command. The problem is that Tcl's "exec" command considers it an error if a subprocess writes anything to stderr. However, a number of modules write warnings or even just informational messages to stderr as well as writing machine-readable output to stdout. There are several possibilities, all of which have drawbacks: 1. If stderr isn't redirected, any warnings or messages will cause the command to fail. 2. If stderr redirected to /dev/null (or nul: on Windows), actual error messages which could identify the cause of the problem will be lost. 3. Merging stderr with stdout isn't an option if stdout is to be passed to another program which is expecting data in a particular format. 4. If stderr is redirected to gis.m's stderr (typically the terminal), messages may be ignored if the user doesn't normally use the terminal. Also, this requires that gis.m actually has a stderr, which isn't necessarily the case if gis.m is launched via the desktop (e.g. the "Start Menu" etc). 5. Redirecting stderr to a file then reading it afterwards requires additional code. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
