[GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows

[Glynn Clements]

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 <glynn at gclements.plus.com>