[GRASS-dev] Unclean exit in 6.5: pgrep issue
glynn at gclements.plus.com
Sun Nov 8 12:36:53 EST 2009
Maris Nartiss wrote:
> >> 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
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
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev