Glynn:
> > pgrep itself isn't remotely portable, and shouldn't be used.
duly noted.
Markus:
> Should I revert the change?
I'll work on a replacement asap.
probably start with ps|grep & double checking the IEEE/SUS for portability.
I wouldn't rely upon the output from "ps" conforming to any particular
standard.
leaving the check off means a few second delay every time you exit, even
if you never started the tcl/tk gui, which is too annoying to let live.
How about only performing the check if Init.sh actually started gis.m?
This won't catch the case where the user started it manually from the
shell, but in that case it's debatable whether Init.sh should be
killing it automatically.
leaving the check off means a few second delay every time you exit, even
if you never started the tcl/tk gui, which is too annoying to let live.
How about only performing the check if Init.sh actually started gis.m?
This won't catch the case where the user started it manually from the
shell, but in that case it's debatable whether Init.sh should be
killing it automatically.
Sorry for jumping in, but could You, please, give an example (use
case) why it makes sense to NOT close any open gis.m sessions on
init.sh exit? Any action issued by gis.m will fail as it's not an
standalone application. Why leave user with open and non-functioning
application windows? Or is this that "You get what You deserve"
attitude to endusers?
>> leaving the check off means a few second delay every time you exit, even
>> if you never started the tcl/tk gui, which is too annoying to let live.
>
> How about only performing the check if Init.sh actually started gis.m?
>
> This won't catch the case where the user started it manually from the
> shell, but in that case it's debatable whether Init.sh should be
> killing it automatically.
Sorry for jumping in, but could You, please, give an example (use
case) why it makes sense to NOT close any open gis.m sessions on
init.sh exit? Any action issued by gis.m will fail as it's not an
standalone application.
I forgot that Init.sh will delete the $GISRC file when it exits.
Or is this that "You get what You deserve" attitude to endusers?
No, it's more a case of "there's a limit to how much effort you should
expend on trying to achieve the impossible". Particularly if you end
up breaking something which would otherwise work.
You cannot guarantee being able to enumerate processes which are
descended from the session shell (/proc may not be mounted, or you may
be running on a Unix where "ps" requires certain privileges). Even if
you can determine that some processes are running $GRASS_WISH, gis.m
may be using a different "wish" (e.g. if GRASS_WISH is overridden in
~/.grass.bashrc). And even if they're using the same "wish", the user
may have run the grass64 script with DISPLAY unset (or set
incorrectly), then set it manually from the shell, so invoking
$GRASS_WISH from Init.sh will fail due to missing or incorrect
$DISPLAY.
If you really want to kill gis.m (and similar) processes launched from
a particular session, it would be more robust (and possibly simpler)
to modify gis.m to self-terminate when the the $GISRC file ceases to
exist.
fwiw, yesterday I committed a chnage to 6.5 (we are only talking about
6.5 btw) which removed the pgrep and added 'ps -a | grep -c $GRASS_WISH'
iiuc on BSD and GNU versions alike you can see what you are running that
way, so fingers crossed. if it fails all it means is that you have to sit
through the extra second or two delay while the gis.m magic does its thing.
(it is not dumb simply trying to `killall wish`, afaiu Maris's tcl magic
registers the PID of the gis.m session upon launch and attempts to cleanly
shut that down on Init.sh exit)
(it is not dumb simply trying to `killall wish`, afaiu Maris's tcl magic
registers the PID of the gis.m session upon launch and attempts to cleanly
shut that down on Init.sh exit)
Specifically, it uses wish to "send" a Gm::remoteExit command to each
"wish" it can find (via "winfo interps"). Gm::remoteExit takes the
session PID ($GIS_LOCK) as an argument, and only terminates if the
process belongs to that session.
There are many ways that this can fail to terminate a gis.m process
which should be terminated, but it's highly unlikely[1] to cause
problems for unrelated processes.
[1] Although theoretically possible. Because it only checks the PID,
and not the hostname, you could have two GRASS sessions on different
hosts but with the same PID, both running gis.m on the same X display.
In this case, both gis.m processes would be terminated.