Paul Kelly wrote on GRASS dev ML:
I think it's a good idea to change the behaviour here,
but I feel the patch doesn't really address the problem:
rather it adds more code to work around it. In
particular, clicking exit in the gis_set.tcl Window won't
work with init.bat (Windows) now, as it used the exit
code of 1 to indicate exit (whereas the patch makes an
exit code of 2 now indicate exit). I notice also the
patch makes the exit code of the Python version of
gis_set.tcl be interpreted differently - has anybody
checked what effect this will have?
The problem is the historical behaviour that an error in
gis_set.tcl (e.g. the wrong version of Tcl/Tk) caused it
to drop out from attempting the GUI startup but go ahead
and start an interactive GRASS shell. When I made a few
changes to the return codes from gis_set.tcl I
deliberately avoided tackling this because I wasn't sure
what was the best solution. But on thinking about it
more, I think dropping to an interactive shell is the
wrong approach. It should print a warning/error message
and then exit, and if the user wants to start in
text-based mode instead they can use the -text switch
next time round.
init.bat assumes a return code of 1 means exit. I vaguely
intended the same interpretation for Init.sh, and to
remove the facility to drop to an interactive shell when
there was an error in gis_set.tcl, but I didn't implement
this nor tell anybody about my plans: my fault ;)
I think it would simplify things if we made Init.sh
always exit when a non-zero exit code is returned from
gis_set.tcl- any other thoughts? (I should probably
update init.bat too so it goes ahead when 0 is returned,
rather than exiting when 1 is returned).
----------------------------------------------------------------------
You can respond by visiting:
http://wald.intevation.org/tracker/?func=detail&atid=204&aid=478&group_id=21
