[GRASS-dev] another not quiet GRASS command

Michael Barton Michael.Barton at asu.edu
Sun Sep 2 14:43:44 EDT 2007


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?)

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. It
does nothing except lock up scripts that don't make special arrangements to
parse such stuff. 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. 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. 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.

Michael
__________________________________________
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