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

[Glynn Clements]

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 
> pointless.

Right.

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.

> Possible problems with and notes about the above code:

> - Output issued to stderr but when the command has exited successfully 
> should be handled by the second block of the if statement, and popped up 
> for the user to read and then continue.

I'm not sure that you get that option. If the command writes to
stderr, exec fails. I don't think that it's guaranteed that the
command will be run to completion, so I wouldn't want to rely upon it.

> - To be neater and less confusing to the user, the possiblity of a command 
> exiting with a non-zero return code but not writing anything to stderr 
> should probably also be handled.

In this particular case, there are only really two possibilities:
either the command's interface description was successfully retrieved,
or it wasn't. It probably isn't worth trying to discern between
different types of failure.

-- 
Glynn Clements <glynn at gclements.plus.com>