Hi
Ma-ris Narti¹s has submitted a patch into GForge [1]. I'm copying his
message below. Please somebody review and submit.
Date: 2007-09-20 08:54
Sender: Ma-ris Narti¹sThere was wrong use of "eval" in startup script (init.sh).
I fixed it and also changed startup screen return code to 2 for
clean exit from GRASS.Somebody with enough karma please commit attached patch to CVS.
[1]http://wald.intevation.org/tracker/?func=detail&atid=204&aid=478&group_id=21
On 20/09/07 11:25, Maciej Sieczka wrote:
Hi
Ma-ris Narti¹s has submitted a patch into GForge [1]. I'm copying his
message below. Please somebody review and submit.
Just tested and it seems to work. Committed.
Thanks Maris !
Moritz
Hello all
(sorry for delayed response on this; been travelling a lot and only have time to "dip in" to mailing list discussions at the minute...)
On Thu, 20 Sep 2007, Moritz Lennert wrote:
On 20/09/07 11:25, Maciej Sieczka wrote:
Hi
Ma-ris Narti?s has submitted a patch into GForge [1]. I'm copying his
message below. Please somebody review and submit.Just tested and it seems to work. Committed.
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).
Paul
Hi, some comments inline.
2007/9/24, Paul Kelly <paul-grass@stjohnspoint.co.uk>:
Hello all
(sorry for delayed response on this; been travelling a lot and only have
time to "dip in" to mailing list discussions at the minute...)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.
Hm. 6 lines isn't a lot and those lines fix probelm instead of
working-a-round 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?
Before this patch GUI exit code was not used at all due wrong use of
eval. It should not affect Python version at all, but I can not test
it as still there is no Gentoo ebuild for recent wx* stuff.
About init.bat You are right - it needs to be fixed. Please, fix this in CVS.
Exit code "2" isn't mandatory, it just can NOT be 0 (success - launch
GRASS) or 1 (error - use some failback or other things for error
handling).
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.
This is debatable question - what's better - provide failback
mechanism or just give error message. IMHO better is to use some
failback, as most errors are trapped within gis_set and exit code 1
should mean some serious error.
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
User exit is not an error. As GRASS is hybrid GUI/CLI system, there
should be some clear exit code for user's canceled action instead of
error.
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).
As I wrote - user exit is not an error. If You think, that GRASS
should not use text mode as failback - that's OK, but still there
should be as minimum 3 cases - no error (start GRASS); error (print
error and exit or use text mode) and user exit (just exit GRASS).
Paul
Thanks for Your input,
Maris.
On Mon, 24 Sep 2007, Maris Nartiss wrote:
2007/9/24, Paul Kelly <paul-grass@stjohnspoint.co.uk>:
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).As I wrote - user exit is not an error. If You think, that GRASS
should not use text mode as failback - that's OK, but still there
should be as minimum 3 cases - no error (start GRASS); error (print
error and exit or use text mode) and user exit (just exit GRASS).
What about:
returns 0: indicates location and mapset set successfully, init script goes on to launch GRASS.
returns 1: indicates user exit, init script exits and returns a value of 0 to the system.
returns any other value: indicates an error, init script exits and returns the value captured to the system (this allows future expansion of the error handling in the GUI gis_set without any changes to either init script).
I guess my only real objection to the patch was that the number 2 seemed like an obscure value to choose for the specific (and common) condition that a user had clicked exit, and that the python version and any future versions of gis_set.tcl would presumably (I haven't checked) need to be modified to return 2 on this condition.
Another option (to make it even clearer that the user clicking exit was a special case and not a "normal" error) could be that that resulted in a return value of -1, and any positive return value indicated an error, but I have no idea how cross-platform/GUI scripting language-compatible that would be.
Paul
Hi Paul,
thanks for Your efforts to standartize exit codes. I agree, that exit
code 2 probably was not best choice.
I looked on [1] and also [2] and I'm not sure that using -1 as exit
code is a good idea. Probably 130 is better choice (Script terminated
by Control-C) - as it's a USERS choice to stop programs execution.
If nobody disagrees (say now or keep mouth shut ;), could You, please,
make necessary changes in gis_set, init.sh/bat?
Maris.
1. http://tldp.org/LDP/abs/html/exitcodes.html
2. /usr/include/sysexits.h
Paul Kelly wrote:
Another option (to make it even clearer that the user clicking exit was a
special case and not a "normal" error) could be that that resulted in a
return value of -1, and any positive return value indicated an error, but
I have no idea how cross-platform/GUI scripting language-compatible that
would be.
Exit codes are limited to 8 bits, so if you return -1, the caller will
see 255.
--
Glynn Clements <glynn@gclements.plus.com>