[GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows
michael.barton at asu.edu
Sat Sep 1 15:40:04 EDT 2007
On 9/1/07 10:37 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:
> Paul Kelly wrote:
>>> Update /gui/tcltk/gis.m/runandoutput.tcl from the cvs and see what happens.
>>> I just made a change, suggested by Glynn, that fixed similar symptoms for
>>> with with another command (v.what). v.what was kicking out extraneous
>>> information when it launched and creating an identical dialog. I've
>>> separated out stderr from the normal stdout information when commands are
>>> launched from the menu and it works fine now.
>> As far as I can see there in that latest change you're redirecting stderr
>> to /dev/null. So now there will be no output for the catch command to
>> catch in case of an error - so printing out the error message is
Maybe this is not what you mean, but I intentionally generated an error to
test this by adding a typo to the menu command to call v.what (made it
"v.whats"). The error message came back as 'v.whats not found'.
So it looks like this will return at least some error messages.
> The reason for the redirect was to prevent extraneous stderr output
> from being treated as an error (v.what was calling R_open_driver()
> before the G_parser() call; with direct rendering, this caused the PNG
> driver startup text ("PNG: GRASS_TRUECOLOR status: ..." etc) to be
> written to stderr.
> I've fixed v.what not to do this. The map= option is now always
> required; it won't try to get a default from the current monitor.
> A few display (d.*) commands still do this, but those don't get run
> from the menus, so this shouldn't be an issue. This isn't an issue for
> wxGRASS, as Python has better subprocess management.
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
More information about the grass-dev