hi,
can someone please explain to me what is happening in this change?
I don't understand what it does.
https://trac.osgeo.org/grass/changeset/39326
thanks,
Hamish
You need more comments to such small code ammount?
Reason: launch Your file manager (Dolphin, Konqueror, Nautilus etc.),
navigate to /usr/bin/ and click on grass65 to start GRASS. Before this
patch gis.m was starting fine without any terminal (xterm), still
after exiting from gis.m, init.sh doesn't clean up - leves .lock's
etc. This patch just launches somekind of interactive terminal/konsole
if there isn't one. It should not affect anyone who is launching GRASS
in "normal" way - from terminal/console or by shortcut that starts
some console.
test -t 0 - check if stdin is connected to terminal
xdg-terminal - utility from Portland project that should start user's
preffered terminal (xdg-utils CVS only. Present on Debian and iirc
Fedora)
exec xterm -e - execute xterm and launch provided programm in xterm.
-e is supported by most (if not all) xterm like terminals (konsole,
gnome-terminal et.al). If user has set GRASS_XTERM in his gisrc file,
then it replaces xterm.
I hope now You understand how insignificant this change is, as
"normal" users don't play around with their file browsers.
Maris.
2009/9/29, Hamish <hamish_b@yahoo.com>:
hi,
can someone please explain to me what is happening in this change?
I don't understand what it does.https://trac.osgeo.org/grass/changeset/39326
thanks,
Hamish
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
2009/9/29 Maris Nartiss <maris.gis@gmail.com>:
You need more comments to such small code ammount?
[...]
probably Hamish is not alone who appreciated more comments, at least also me;-)
Thanks for clarification, Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Come on now, Maris, be fair. We all know shell code
gets more cryptic the shorter it is 
But does that mean there is no longer any way to start
GRASS without also launching a terminal emulator?
Personally, I don't mind (and neither will probably anyone
who uses a Unix system). However, I was under the impression
that it was desirable to have a way to start GRASS
with no terminal attached, especially for Windows users.
Plus, one of the long-term goals for GRASS was to drop
all dependencies on bash. I don't know in how far an
enforced terminal window agrees with that.
The problem with init.sh remains, of course. But surely
that could be handled by an exit function in gis.m?
But maybe I am thinking in the wrong direction here...
Ben
----- Original Message -----
From: "Maris Nartiss" <maris.gis@gmail.com>
To: "Hamish" <hamish_b@yahoo.com>
Cc: "grass-dev" <grass-dev@lists.osgeo.org>
Sent: Tuesday, September 29, 2009 9:04:57 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [GRASS-dev] what's going on in r39326
You need more comments to such small code ammount?
Reason: launch Your file manager (Dolphin, Konqueror, Nautilus etc.),
navigate to /usr/bin/ and click on grass65 to start GRASS. Before this
patch gis.m was starting fine without any terminal (xterm), still
after exiting from gis.m, init.sh doesn't clean up - leves .lock's
etc. This patch just launches somekind of interactive terminal/konsole
if there isn't one. It should not affect anyone who is launching GRASS
in "normal" way - from terminal/console or by shortcut that starts
some console.
test -t 0 - check if stdin is connected to terminal
xdg-terminal - utility from Portland project that should start user's
preffered terminal (xdg-utils CVS only. Present on Debian and iirc
Fedora)
exec xterm -e - execute xterm and launch provided programm in xterm.
-e is supported by most (if not all) xterm like terminals (konsole,
gnome-terminal et.al). If user has set GRASS_XTERM in his gisrc file,
then it replaces xterm.
I hope now You understand how insignificant this change is, as
"normal" users don't play around with their file browsers.
Maris.
2009/9/29, Hamish <hamish_b@yahoo.com>:
hi,
can someone please explain to me what is happening in this change?
I don't understand what it does.https://trac.osgeo.org/grass/changeset/39326
thanks,
Hamish
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
On Tue, Sep 29, 2009 at 9:04 PM, Maris Nartiss <maris.gis@gmail.com> wrote:
This patch just launches somekind of interactive terminal/konsole
if there isn't one. It should not affect anyone who is launching GRASS
in "normal" way - from terminal/console or by shortcut that starts
some console.
Well, but how about the batch mode? I cannot dig into your code right
now to understand if that's broken now... I am using scripts to launch
GRASS batch jobs. That continues to work? I hope so 
Markus
Hello everyone.
I was not expecting so much communication for such little change. I
must blame my language sk33lz as I'm not able to explain what it does
First - Markus - only way how to really check wheither batch jobs are
broken is to test that. Theoretically if You have set GRASS_BATCH_JOB
env variable You should be just fine.
Second - what was broken, still is broken. GRASS still fails to launch
with tcsh and other sh/bash incompatible shells (grep export
lib/init/* | wc -l).
Third - Benjamin - "Code that was hard to write should be hard to
read" There has never been a way how to start GRASS by its launch
script without terminal. BATCH_JOB thing is a just hack-in to get
around init.sh legacy design. I seriously doubt that Windows users are
using sh to launch GRASS (especially /bin/sh), still, if they do, they
need a terminal. Normaly this change should affect only careless Linux
users.
This change is commited to 6.5 and probably after testing should go to
6.4. In GRASS 7 we can do what we want.
I have old patches lying around in GForge that where providing GUI
cleanup on shell exit and gis.m option to terminate GRASS session. I
will try to get tem into 6.5 asap.
Those, who don't get reason of this change, please, perform following
steps in GRASS 6.4:
1) Start file browser;
2) Navigate to grass64 executable file (/usr/bin/grass64);
3) Launch it;
4) Start GRASS (this will fail if default GUI is text);
5) Close GUI;
6) ps fax | grep -C 3 sh
Steps 1, 2 and 3 can be replaced with ALT+F2 grass64 <ENTER>
Notice - in step 6 You will see Init.sh process that avaits user
input, still it's stdin and stdout are not connected to any terminal.
Now it's impossible to cleanly terminate GRASS - only kill and then
manually clean up.
I hope now I have adressed everyones concerns. If something doesn't
work as it should because of this commit, then report it as a bug
Maris.
2009/9/29, Markus Neteler <neteler@osgeo.org>:
On Tue, Sep 29, 2009 at 9:04 PM, Maris Nartiss <maris.gis@gmail.com> wrote:
This patch just launches somekind of interactive terminal/konsole
if there isn't one. It should not affect anyone who is launching GRASS
in "normal" way - from terminal/console or by shortcut that starts
some console.Well, but how about the batch mode? I cannot dig into your code right
now to understand if that's broken now... I am using scripts to launch
GRASS batch jobs. That continues to work? I hope soMarkus
Hello all,
If I understand correctly, the patch is attempting to solve two separate issues:
1) When starting GRASS by double-clicking on the grass64.sh icon, the user doesn't get a terminal window in which to enter GRASS commands.
2) GRASS doesn't exit properly because the Init.sh runs in the background waiting for user input that never arrives.
Point (1) seems to me just an issue of user preference. I would be wary of anything that assumes the user is wrong, or the user doesn't know what they want, which this fix seems to do. Perhaps they only want the GUI and don't want a terminal window to pop up?
Regarding point (2), why not just launch the GUI in the foreground instead of the background? When it exits, control will be returned to Init.sh which can then clean up and exit. The check for whether there is no terminal attached could be used to force GUI rather than text mode.
What do you think?
Paul
Hi Maris,
On Wed, Sep 30, 2009 at 9:59 AM, Maris Nartiss <maris.gis@gmail.com> wrote:
Hello everyone.
I was not expecting so much communication for such little change. I
must blame my language sk33lz as I'm not able to explain what it does
First - Markus - only way how to really check wheither batch jobs are
broken is to test that. Theoretically if You have set GRASS_BATCH_JOB
env variable You should be just fine.
Well, I don't think that the concept could be to accept breakage of
existing things to fix another issue. In general, it should be task
of the person who makes the change to assure that functionality
close-by (same file) remains. At least as much as possible.
In any case, I'll test myself as well since the GRASS_BATCH_JOB
functionality is essential for my daily GIS work.
Markus
<rant>
It's impossible for single person who spends only hes free time for
development to check all possible scenarious on all possible
hardware/software versions. If code looks sane, we need to assume that
it works unless somebody provides evidence that it doesn't work. I
don't have a Mac (I saw one last year when we had guest lecturer from
Germany), nor grid running supercomputer, neither I run GRASS on
windows. Neither I can imagine any (abusive) way how GRASS is run or
used. Sorry. I have to relay on other GRASS developers who run such
software to test various GRASS parts. Linux developers break GRASS on
Mac. Mac developers break GRASS on Linux. Both break GRASS on Windows.
That's how GRASS development is going already for long time and I
don't see how it could be changed in nearerst future (unless somebody
get's paid for developing and testing everyting on anything). Unless
GRASS gets paid full time developer team, we have to accept, that
development branches (trunk, devel) migh be broken time to time and
that we (developers, users) have to keep an eye on any new bugs
introduced by ourselfs or others.
</rant>
As I wrote - if GRASS_BATCH_JOB is set, everything *should* be fine. I
tested on my Gentoo Linux box and GRASS was able to run from cron when
GRASS_BATCH_JOB was set. Still I can *not* give any guarantee that it
may not be broken on some rare system. Starting GRASS without
GRASS_BATCH_JOB by it's startup script (grassxy + init.sh) is abuse
and should be eliminated.
As for launching plain GUI without terminal - IMHO we should not
change this within 6.x timeframe. As I wrote - GRASS 7 is open for new
ideas.
As all of You like shell code I commited anotherone snippet. Feel
free to discuss 
https://trac.osgeo.org/grass/changeset/39350
(Not tested on Mac or Windows. wxGUI should be unaffected, still not
tested as wxGUI doesn't work on my Linux box at all (6.4, 6.5, 7).
wxGUI devs - what's happening if user closes terminal before closing
wxGUI? IMHO wxGUI also should be cleaned up in case of exit from GRASS
and also should provide a way how to terminate not only GUI but also
whole GRASS session.)
Maris (just freaking out).
PS. Now I understand why GRASS has issues. Such huge discussion for
small change and no serious feedback for large and serious changes as
per r39323 
2009/9/30, Markus Neteler <neteler@osgeo.org>:
Hi Maris,
On Wed, Sep 30, 2009 at 9:59 AM, Maris Nartiss <maris.gis@gmail.com> wrote:
Hello everyone.
I was not expecting so much communication for such little change. I
must blame my language sk33lz as I'm not able to explain what it does
First - Markus - only way how to really check wheither batch jobs are
broken is to test that. Theoretically if You have set GRASS_BATCH_JOB
env variable You should be just fine.Well, I don't think that the concept could be to accept breakage of
existing things to fix another issue. In general, it should be task
of the person who makes the change to assure that functionality
close-by (same file) remains. At least as much as possible.In any case, I'll test myself as well since the GRASS_BATCH_JOB
functionality is essential for my daily GIS work.Markus
On Wed, Sep 30, 2009 at 1:10 PM, Maris Nartiss <maris.gis@gmail.com> wrote:
...
PS. Now I understand why GRASS has issues. Such huge discussion for
small change and no serious feedback for large and serious changes as
per r39323
Look: only on request you explained the change which can break
things five minutes before the final release. That's the "problem".
Of course it applies to all developers that review is needed and
should not end in a flame war.
Discussion is *not* an issue. It's called peer review instead.
Let's keep calm...
Markus
thanks all for the clarifications. The bit which was missing
for me was finding context for it due to the "why".
Paul Kelly wrote:
If I understand correctly, the patch is attempting to solve
two separate issues:1) When starting GRASS by double-clicking on the grass64.sh
icon, the user doesn't get a terminal window in which to
enter GRASS commands.
this should be handled by ticking the "run in terminal" box
when setting up the launcher.
In the latest Debian package we have set 'needs="text"' in the
menu entry:
http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/grass.menu
(just added in svn65 source gui/icons/, other branches soon)
and "Terminal=True" in the desktop icon setup:
http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/grass.desktop
(already in source in gui/icons/)
and to complete the offerings a "x-grass" script for starting
grass in a terminal without needing to set it up as above.
for now it exits with error if it can't get a terminal.
http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/x-grass
(this was debian bug#503371)
maybe those help.
IMO the packaging is the correct place to set this stuff up.
As mentioned by others there are valid times when you don't
want a terminal. (the WinGrass installers don't open terminals
unless you ask for them) [note some .sh replaced by .bat there]
2) GRASS doesn't exit properly because the Init.sh runs in
the background waiting for user input that never arrives.
the above should take care of that. At least from the GRASS
desktop icon the last thing I see is "cleaning up temp files.."
veering off-topic:
IMO it is a mistake to have shutting down the GUI try to close
down the terminal as well. If GUI is started from the terminal
with g.gui this is definitely not what you want.
Paul:
Point (1) seems to me just an issue of user preference. I
would be wary of anything that assumes the user is wrong, or
the user doesn't know what they want, which this fix seems
to do. Perhaps they only want the GUI and don't want a
terminal window to pop up?
I agree
Regarding point (2), why not just launch the GUI in the
foreground instead of the background? When it exits, control
will be returned to Init.sh which can then clean up and
exit. The check for whether there is no terminal attached
could be used to force GUI rather than text mode.
fyi in 6.5 and 7 g.gui now backgrounds the gui, but the init.sh
and AFAIK guis themselves do not. (I think gis.m used to)
thanks,
Hamish
Maris wrote:
> PS. Now I understand why GRASS has issues. Such huge
> discussion for small change and no serious feedback for
> large and serious changes as per r39323
this is known as the bike-shed problem, and is not unique to
GRASS, or even software. see
http://en.wikipedia.org/wiki/Bike_shed
http://bikeshed.com/
in this case I like to keep my head around everything that
Init.sh does, and saw something I couldn't follow. Education
and communication is universally good. Any modification to
the critical main startup script is by definition serious.
MN:
change which can break things five minutes before the final
release.
In Maris's defence, this change was only in 6.5. (?right?)
regards,
Hamish
This is hottest topic of the month! Will I get extra geek points for
starting it?
2009/9/30, Hamish <hamish_b@yahoo.com>:
thanks all for the clarifications. The bit which was missing
for me was finding context for it due to the "why".
Yeah. Sorry. GRASS startup is a bit of code and a lot of black magick
Paul Kelly wrote:
If I understand correctly, the patch is attempting to solve
two separate issues:1) When starting GRASS by double-clicking on the grass64.sh
icon, the user doesn't get a terminal window in which to
enter GRASS commands.this should be handled by ticking the "run in terminal" box
when setting up the launcher.
Doesn't apply.
In the latest Debian package we have set 'needs="text"' in the
menu entry:
http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/grass.menu(just added in svn65 source gui/icons/, other branches soon)
Doesn't apply.
and "Terminal=True" in the desktop icon setup:
http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/grass.desktop(already in source in gui/icons/)
Doesn't apply.
and to complete the offerings a "x-grass" script for starting
grass in a terminal without needing to set it up as above.
for now it exits with error if it can't get a terminal.
http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/x-grass(this was debian bug#503371)
GRASS 6.5 should now work without any Debian-specific workarounds in
more universal way (non-hardcoded paths, xdg-utils from Portland
project).
maybe those help.
IMO the packaging is the correct place to set this stuff up.
This patch addresses those users who for some reason are NOT using
packagers provided way of running GRASS.
Consider following scenarios that now work correctly:
Joe The Averageuser compiles GRASS on Slackware (good old times) and
creates symlink on his Desktop to /usr/bin/grasXY
Jane The Poweruser uses KDE run quicklauncher to start grassXY (thus
NOT using any .desktop files with proper terminal=required
mumbo-jumbo).
As mentioned by others there are valid times when you don't
want a terminal. (the WinGrass installers don't open terminals
unless you ask for them) [note some .sh replaced by .bat there]
Valid time users use valid approaches. If something works by accident,
it shouldn't be considered a norm.
2) GRASS doesn't exit properly because the Init.sh runs in
the background waiting for user input that never arrives.the above should take care of that. At least from the GRASS
desktop icon the last thing I see is "cleaning up temp files.."
You can't see anything without a terminal.
veering off-topic:
IMO it is a mistake to have shutting down the GUI try to close
down the terminal as well. If GUI is started from the terminal
with g.gui this is definitely not what you want.
As GRASS 6.x consists of CLI part (terminal) and GUI *on top of it*, I
agree. My commits don't change GRASS 6.x components (CLI+GUI). If we
are dropping CLI (terminal) in GRASS 7, then startup parts and GUI
should be build there (trunk) around new paradigm but, please, do not
change 6.x version.
Still in r39350 I have added gis.m option to terminate GRASS session
besides usual exit gis.m option. It's a bit of kludge as gis.m is not
tightly coupled with other GRASS parts (Init.sh). It migh require
aditional hacking on Mac and Windows to provide equivalent
functionality there (no idea). Still it's better than nothing.
Paul:
Point (1) seems to me just an issue of user preference. I
would be wary of anything that assumes the user is wrong, or
the user doesn't know what they want, which this fix seems
to do. Perhaps they only want the GUI and don't want a
terminal window to pop up?I agree
GRASS 6.x paradigm is CLI + GUI. It's how it is designed and most of
existing tutorials also assume presence of terminal that provides CLI.
Regarding point (2), why not just launch the GUI in the
foreground instead of the background? When it exits, control
will be returned to Init.sh which can then clean up and
exit. The check for whether there is no terminal attached
could be used to force GUI rather than text mode.fyi in 6.5 and 7 g.gui now backgrounds the gui, but the init.sh
and AFAIK guis themselves do not. (I think gis.m used to)
If GUI doesn't release terminal after startup in GRASS 6 (on Linux),
it should be considered a bug and should be fixed. gis.m does this,
can't test wxgui, as it's still broken on Linux.
thanks,
Hamish
All of You have three options:
fix code/report bug/revert
Can we move on?
Maris.
no time for a full reply now but,
the .desktop and .menu are not entirely specific to Debian and
are provided as uninstalled templates as a convenience to the
source code user, if only for inspiration. If they were to be
added to the Makefiles they would be renamed *.in and have paths
filled in at build time.
Maris wrote:
Consider following scenarios that now work correctly:
Joe The Averageuser compiles GRASS on Slackware (good old
times) and creates symlink on his Desktop to /usr/bin/grasXY
Joe as a slackware user should know better than to do that
with a terminal app.
Jane The Poweruser uses KDE run quicklauncher to start
grassXY (thus NOT using any .desktop files with proper
terminal=required mumbo-jumbo).
Jane as a power-user should know that she has to tick the
"Terminal required" box in the quicklauncher setup. She
doesn't have to know about the internals of the quicklauncher
mechanism.
Valid time users use valid approaches. If something works
by accident, it shouldn't be considered a norm.
I don't really understand your meaning, but current GRASS 6.x
on MS-Windows without a terminal is no accident. It's the result
of a lot of hard work.
Hamish:
> veering off-topic:
> IMO it is a mistake to have shutting down the GUI try
> to close down the terminal as well.
fwiw I wrote that before I noticed your latest commit, and was
speaking about automatic shutdown on exit, not user-chosen.
I don't want to tell folks what to work on, but as mentioned
in the nviz email, at some point we should stop adding new
features to the tcltk stuff and focus development in trunk on
wx things. [this one had been discussed in the ML and trackers,
and so was already in the pipeline so isn't exactly "new"]
regards,
Hamish
Ciao tutti,
2009/9/30 Maris Nartiss <maris.gis@gmail.com>:
[...]
(Not tested on Mac or Windows. wxGUI should be unaffected, still not
tested as wxGUI doesn't work on my Linux box at all (6.4, 6.5, 7).
wxGUI devs - what's happening if user closes terminal before closing
wxGUI? IMHO wxGUI also should be cleaned up in case of exit from GRASS
and also should provide a way how to terminate not only GUI but also
whole GRASS session.)
simply wxGUI remains broken, please fill ticket for that. Personally
no time to fix it.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Maris Nartiss wrote:
I hope now You understand how insignificant this change is, as
"normal" users don't play around with their file browsers.
Actually, it's quite fundamental. The split between the grassXX script
and Init.sh is quite deliberate; the grassXX script sets GISBASE then
invokes Init.sh, and that's all it does. Everything which can go into
Init.sh does so.
Obviously, setting GISBASE can't go into Init.sh, because $GISBASE is
needed to locate Init.sh. The whole point of the split is so that
Init.sh doesn't contain any hard-coded paths. The one and only
hard-coded path (GISBASE) goes into the grassXX script, and everything
else goes into Init.sh.
Unless someone has beaten me to it, I will revert r39326.
--
Glynn Clements <glynn@gclements.plus.com>