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

[Paul Kelly]

Hello Michael

On Sat, 25 Aug 2007, Michael Barton wrote:

> Moritz,
>
> 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. In any case a popup dialog should be a better option than 
printing to the terminal where the user might not notice it until later - 
or in future there may not even be a terminal, e.g. in WinGRASS but maybe 
we'll change that.

I'd suggest using the catch command something as follows (this is adapting 
what's in epsg_option.tcl):

catch {set code [exec -- $program --tcltk]} errMsg

if {[lindex $::errorCode 0] eq "CHILDSTATUS"} {
     DialogGen .wrnDlg [G_msg "Error running command!"] warning \
     [format [G_msg "%s returned the following message:\n%s"] $program $errMsg] \
     0 OK
} elseif {$errMsg != ""} {
         DialogGen .wrnDlg [format [G_msg "Informational output from %s"] $program] info \
         [format [G_msg "%s returned the following informational message:\n%s"] $program $errMsg] \
         0 OK
     }
}

DialogGen is a nice little routine in gis_set.tcl that pops up a dialog 
box. There are some comments in gis_set.tcl on how to use it.

Please note that I'm not saying this is what you should do, nor that I 
necessarily recommend doing it now - my original comments about catching 
errors properly where really just suggestions about something that we 
should look out for in the future, as I thought it would be too much work 
do do it thoroughly and properly now so soon before 6.3.0 without 
introducing new unexpected behaviour and so on.

Possible problems with and notes about the above code:
- With the catch where it is - I'm not sure if it actually catches the 
"exec" command or just the "set" command
- Checking the return status of the command is better than checking the 
return value of catch, because, as we've seen lots of times - Tcl will 
assume an error has happened if *any* output is written to stderr - a 
usage convention not shared by GRASS.
- 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.
- 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.

Paul