[GRASS-dev] How GRASS should behave when another session is already active?

Markus Neteler neteler at osgeo.org
Tue Jun 2 03:34:30 PDT 2015


On Tue, Jun 2, 2015 at 3:05 AM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
> Hi all,
>
> I need opinions on how to resolve the question whether GRASS session can be
> started from another GRASS session.
>
...
> I think starting non-interactive session (batch/exec mode) should be
> possible.

Maybe yes.

> Perhaps interactive session (--text & --gui) should have the
> check.

Definitely. IMHO there is no point in starting GRASS GIS as
interactive session from within GRASS - only asking for troubles. Or
is there any use case where this makes sense?

> If the check is present (even just for the interactive sessions), the
> OSGeo4W version (and probably standalone winGRASS too) is going to break
> (needs to be changed somehow).

Why does the OSGeo4W break? This is not clear to me.

> Moreover, this would disallow setting some
> GISBASE to system for scripting purposes ("without starting explictly") and
> then starting a standard session.

.. you mean in the non-interactive case.

> The issue with the current state is that you cannot run different version of
> GRASS from a current session.

... yes, luckily :-)

> More serious issue is that you cannot start
> another version if you have GISBASE in your system environment for scripting
> purposes (as mentioned above). The current behavior may also differ
> depending on a platform.

Cannot we suggest to the user via test to remove that variable? Rather
than overriding it?

> I'm not really sure what were the original intentions but I would prefer to
> switch the logic in r45576 and use GISBASE only if the path from compile
> time does not exist. This allows to override current session (GISBASE set in
> some way) but allows to supply the GISBASE when there is something wrong
> with compile time path. I would use some advice because I don't know how
> this works on Windows and Mac nor what grass.sh file is supposed to do.

I cannot comment yet on this unless I fully understand the issue (see
questions above).
Probably the pseudo-code should go into a trac page?

Markus


More information about the grass-dev mailing list