Re: [GRASS-dev] start grass with only initializing the environment
Hamish 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: RMKruggmailcom
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] start grass with only initializing the environment
Markus Neteler writes: > On Mon, Jul 15, 2013 at 5:44 PM, Rainer M Krug 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: RMKruggmailcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] start grass with only initializing the environment
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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] start grass with only initializing the environment
On Mon, Jul 15, 2013 at 5:44 PM, Rainer M Krug 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] start grass with only initializing the environment
The following message is a courtesy copy of an article that has been posted to gmane.comp.gis.grass.devel as well. 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: RMKruggmailcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
