On 24/09/07 19:55, grass-dev@grass.itc.it wrote:
code I item #478, was opened at 2007-09-07 15:40
Status: Open
Priority: 3
Submitted By: Moritz Lennert (moritz)
Assigned to: Māris Nartišs (marisn)
Summary: tcl/tk gui startup screen launches grass even when 'Exit' is pushed Issue type: other bug
Issue status: confirmed
GRASS version: CVS HEAD
GRASS component: startup
Operating system: Linux
Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070903
Comment By: Maciej Sieczka (msieczka)
Date: 2007-09-24 19:55
Message:
The issue is more complicated. According to Paul Kelly the committed fix is not complete. See Details Below:
Where are we at with this issue ? At this point it is still not solved for wingrass and for other platforms I don't know if the solution currently in CVS for init.sh is deemed satisfactory.
Moritz
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
On 24/10/07 13:27, Moritz Lennert wrote:
On 24/09/07 19:55, grass-dev@grass.itc.it wrote:
code I item #478, was opened at 2007-09-07 15:40
Status: Open
Priority: 3
Submitted By: Moritz Lennert (moritz)
Assigned to: Māris Nartišs (marisn)
Summary: tcl/tk gui startup screen launches grass even when 'Exit' is pushed Issue type: other bug
Issue status: confirmed
GRASS version: CVS HEAD
GRASS component: startup
Operating system: Linux
Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070903
Comment By: Maciej Sieczka (msieczka)
Date: 2007-09-24 19:55
Message:
The issue is more complicated. According to Paul Kelly the committed fix is not complete. See Details Below:
Where are we at with this issue ? At this point it is still not solved for wingrass and for other platforms I don't know if the solution currently in CVS for init.sh is deemed satisfactory.
Current state:
- gis_set.tcl returns 2 when exit button is pushed.
- init.bat expects 1 for exit, any other value prompts the startup of grass gui.
So, for the current wingrass binaries to work I will just changes init.bat to expect 2, but as there was discussion concerning the "correct" value, it would be better to decide this once and for all.
Moritz
Moritz
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
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
On 10/24/07 4:27 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
On 24/09/07 19:55, grass-dev@grass.itc.it wrote:
code I item #478, was opened at 2007-09-07 15:40
Status: Open
Priority: 3
Submitted By: Moritz Lennert (moritz)
Assigned to: M?ris Narti¹s (marisn)
Summary: tcl/tk gui startup screen launches grass even when 'Exit' is pushed
Issue type: other bug
Issue status: confirmed
GRASS version: CVS HEAD
GRASS component: startup
Operating system: Linux
Operating system version:
GRASS CVS checkout date, if applies (YYMMDD): 070903
Comment By: Maciej Sieczka (msieczka)
Date: 2007-09-24 19:55
Message:
The issue is more complicated. According to Paul Kelly the committed fix is
not complete. See Details Below:
Where are we at with this issue ? At this point it is still not solved
for wingrass and for other platforms I don't know if the solution
currently in CVS for init.sh is deemed satisfactory.
Moritz
It works fine for me with Mac OS X in GRASS 6.3
Michael
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:
Wald: Exiting with error
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On 24/10/07 21:23, Michael Barton wrote:
On 10/24/07 4:27 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
Where are we at with this issue ? At this point it is still not solved
for wingrass and for other platforms I don't know if the solution
currently in CVS for init.sh is deemed satisfactory.
Moritz
It works fine for me with Mac OS X in GRASS 6.3
Yes, it was fixed (temporarily) for *nix environments. But there was debate on whether the return codes used were the "correct" ones. In the current windows binaries I applied the same fix, for now, but was wondering whether there was a more definitive way to do it.
Moritz