Hi, some comments inline. 2007/9/24, Paul Kelly <[EMAIL PROTECTED]>: > 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. _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
