[GRASS-dev] another not quiet GRASS command

Michael Barton michael.barton at asu.edu
Mon Sep 3 15:52:21 EDT 2007


So what is *supposed* to happen in a scripting environment is...

1) non-zero exit code returned
2) show whatever is in stderr to the user

OR

1) 0 exit code returned
2) do not report with whatever is in stderr (not because it is unimportant,
but because it is not an error)

Correct?

If so, then there may be a bug somewhere in cmd.Comand since it is showing
non-meaningful error messages sometimes when the command operates fine.

An aside: g.mapset treats as an error (It says "ERROR", so I assume that it
generates a non-zero exit code) a situation where the location and mapset
are the current location and mapset. IMHO, this should not be an error. I
guess it could be a "warning", but the module is operating correctly in that
it is 'changing' to the location and mapset specified; these just happen to
be the current one.

Michael


On 9/3/07 12:36 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>> I'm trying to use g.mapset in the georectifier module for wxgrass. I have to
>> switch back and forth between locations and mapsets. For TclTk, I used
>> g.gisenv, but thought it would be more convenient to use g.mapset here.
>> 
>> BUT, I've hit the perennial problem of a GRASS command that won't be quiet.
>> Regardless of the --q switch, g.mapset insists on dumping a warning to
>> stderr.
>> 
>> g.mapset mapset=PERMANENT location=Spearfish60_test --q
>> WARNING: Your shell continues to use the history for the old mapset.
>> 
>> This causes cmd.Command (wxgrass command processor using subprocess.Popen)
>> to report an error when there isn't one.
>> 
>> (Martin, this seems to be a general issue with cmd.Command. Is there a way
>> to work around this for commands that insist on dumping extraneous stuff to
>> stderr?)
> 
> If cmd.Command considers writing to stderr to constitute an error,
> that's a bug in cmd.Command.
> 
> That behaviour of Tcl's "exec" is a significant design flaw; it should
> not be intentionally replicated by wxGRASS.
> 
>> This might be a useful warning for command line users to get. But for
>> scripting, I don¹t want to see ANY warnings or other extraneous output.
> 
> Many of the warnings which commands generate are quite important, and
> shouldn't be hidden for the sake of convenience.
> 
> The g.mapset warning is of debatable usefulness (in general; it's
> entirely meaningless for the GUI), but there are plenty of others
> which are useful.
> 
>> It does nothing except lock up scripts that don't make special arrangements
>> to
>> parse such stuff.
> 
> Scripts should not be attempting to parse stderr. The only reasonable
> ways to handle stderr output are:
> 
> 1. Show it to the user.
> 2. Log it to a file.
> 3. Discard it, or otherwise ignore it.
> 
>> This is a real problem for TclTk, leaving us with the
>> necessity of sending all stderr to dev/null so that we only get back error
>> messages sent by TclTk.
> 
> That's a deficiency of Tcl's process management primitives
> ("primitive" being the operative term).
> 
>> Even for languages like wxPython that can separate
>> stderr from stdout, it means that attempts to gracefully trap and display
>> errors will incorrectly show an error when something like this happens.
> 
> Only if the code mimic's Tcl's bogus concept of what constitutes an
> error (i.e. stderr output).
> 
> Writing to stderr is *not* an error. Returning a non-zero exit code is
> an error.
> 
>> It
>> would make life so much easier for scripting if we could optionally turn off
>> ALL returned message except stdout for commands that are supposed to return
>> a value and stderr for real errors.
> 
> That isn't going to happen.
> 
> Apart from the amount of work involved in modifying GRASS, many
> library functions can write warnings (and other messages) to stderr,
> and don't necessarily provide any mechanism to control whether this
> happens, or even to detect that it has happened.
> 
> In general terms, stderr is a mechanism for programs to communicate
> arbitrary information to the *user*. Programs should not get involved
> with reading stderr unless they are doing so in order to act as a
> "common carrier" between the program and the user (i.e. to simply pass
> the information along).

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton






More information about the grass-dev mailing list