[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