[GRASS-dev] start grass with only initializing the environment

Hi

During the recent useR conference I had a discussion with Roger Bivand
about the usage of GRASS from R on a Mac. I got it to work, but I
manually had to adjust library paths as these depend on the way GRASS is
installed (framework, homebrew, MacPorts, which version of GRASS).

So to get GRASS 7 to work from within R, it was required to identify the
paths of the libraries by going through the grass startup script. AS
mentioned above, these paths are not easily portable and to include in
the the spgrass6 startup mechanism.

Therefore the idea occurred, if it would be possible to use the grass
startup script to only set the environmental variables to be able to run
the grass commands.

As other applications do set these environmental variables as well
(cluster, http://osgeo.org/wiki/GRASS_and_Shell , ...) this would be of
wider use the simply when linking R and GRASS.

I would therefore suggest an additional startup argument for grass,
which only sets the environmental variables, including library paths,
so that GRASS commands can be executed afterwards, and if the
LOCATION_NAME and MAPSET are not provided, they will be null and *have
to be set manualy afterwards*.
This could e.g. have the name "-noui" indicating that no ui will be
started.

I think this would be a useful addition and make GRASS easier to use
from other programs via scripting.

Cheers,

Rainer

--
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

On Mon, Jul 15, 2013 at 5:44 PM, Rainer M Krug <Rainer@krugs.de> wrote:
...

I would therefore suggest an additional startup argument for grass,
which only sets the environmental variables, including library paths,
so that GRASS commands can be executed afterwards, and if the
LOCATION_NAME and MAPSET are not provided, they will be null and *have
to be set manualy afterwards*.
This could e.g. have the name "-noui" indicating that no ui will be
started.

I wonder what the difference to starting GRASS 7 with -text is...
Maybe that's already enough?

Markus

Rainer wrote:

I would therefore suggest an additional startup argument for grass,
which only sets the environmental variables, including library paths,
so that GRASS commands can be executed afterwards,

just make your own batch file or function(){} for /etc/bash.bashrc?

and if the LOCATION_NAME and MAPSET are not provided, they will be
null and *have to be set manualy afterwards*.

that doesn't sound like a practice we should promote.

what part of the start up are you trying to avoid? ('grass64 -text'
works in 6 too, or 'g.gui text' to avoid the gui at startup)

see also the usage for GRASS_BATCH_JOB, which basically does that in
a non-interactive environment.

Hamish

Markus Neteler <neteler@osgeo.org> writes:

On Mon, Jul 15, 2013 at 5:44 PM, Rainer M Krug <Rainer@krugs.de> wrote:
...

I would therefore suggest an additional startup argument for grass,
which only sets the environmental variables, including library paths,
so that GRASS commands can be executed afterwards, and if the
LOCATION_NAME and MAPSET are not provided, they will be null and *have
to be set manualy afterwards*.
This could e.g. have the name "-noui" indicating that no ui will be
started.

I wonder what the difference to starting GRASS 7 with -text is...
Maybe that's already enough?

No - this doesn't work.

The idea is to use this from R to set the environmental parameter when
using spgrass6. If I call grass -text from R (all in the terminal), the
grass session opens and I am in grass, but I can not do anything from R,
which I want to do.

So it seems that the grass startup script recognises that it is not in a
shell, and then starts one? If this starting of the shell could be
suppressed, I would expect that starting grass with the -text option
should work. I would assume that this would be similar to setting
GRASS_BATCH_JOB, only that GRASS does not exit automatically.
Something like a GRASS_BATCH_MODE - or one could call it a GRASS_SERVER_MODE?

Cheers,

Rainer

Markus

--
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

Hamish <hamish_b@yahoo.com> writes:

Rainer wrote:

I would therefore suggest an additional startup argument for grass,
which only sets the environmental variables, including library paths,
so that GRASS commands can be executed afterwards,

just make your own batch file or function(){} for /etc/bash.bashrc?

Sure - that is how it works at the moment, but I ran into problems: the
problem were library paths, which were not set (on Mac OS X).

Background: the idea is to use in spgrass6 to make it more robust to
different versions and platforms on which it is used.

and if the LOCATION_NAME and MAPSET are not provided, they will be
null and *have to be set manualy afterwards*.

that doesn't sound like a practice we should promote.

what part of the start up are you trying to avoid? ('grass64 -text'
works in 6 too, or 'g.gui text' to avoid the gui at startup)

Please see my other email, in which I explained why -text does not help
here.

see also the usage for GRASS_BATCH_JOB, which basically does that in
a non-interactive environment.

Exactly - what would be needed, is that GRASS does not exit, but rather
stays in the background and can be used via the spgrass6 command
execGRASS().

Cheers,

Rainer

Hamish

--
Rainer M. Krug

email: RMKrug<at>gmail<dot>com