#3462: Allow setting environment variables in grass startup script
---------------------+-------------------------
Reporter: mankoff | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default | Version: 7.2.2
Keywords: | CPU: Unspecified
Platform: MacOSX |
---------------------+-------------------------
In the grass72 startup script, in the function `def bash_startup(location,
location_name, grass_env_file):`
These lines exist:
{{{
for line in readfile(env_file).splitlines():
if not line.startswith('export'):
f.write(line + '\n')
}}}
If I comment out the 2nd line (and fix the indentation for the 3rd line
because this is Python), then I can add `export DYLD_LIBRARY_PATH=...` in
either `~/.grass.bashrc` or `~/.grass7/bashrc` and this fixes various
GRASS issues on OS X relating to the temporal framework.
Why does the startup script ignores `export` statements from the GRASS
config file? Is there a problem if I change this behavior?
In more detail, this is not an issue with Fink installations, but is with
MacPorts. Fink installs an OS X Application: GRASS.app. Deep in the app I
found a Makefile that seems to tell GRASS.app to respect
`GRASS_LD_LIBRARY_PATH`. The Macports version does not install an app, and
does not respect the `GRASS_LD_LIBRARY_PATH` variable. For some reason,
shell-level `LD_LIBRARY_PATH` and `DYLD_LIBRARY_PATH`'s are also not
respected (perhaps due to SIP?).
Environmental variables are loaded by load_env()
source:grass/trunk/lib/init/grass.py?rev=65585#L1710 from default config
file source:grass/trunk/lib/init/grass.py?rev=65585#L1220. In my case on
Linux (using Bash), it's `~/.grass7/bashrc`. Eg.
{{{
# Set LD_LIBRARY_PATH (etc) to find GRASS shared libraries
# this works for subprocesses but won't affect the current process
path_prepend(gpath("lib"), ld_library_path_var)
}}}
I'm not clear how the comment in `grass.py` pointing to this ticket helps.
Certain critical environment variables that are **required** for GRASS to
work correctly cannot be set in either `~/.grass.bashrc` or
`~/.grass7/bashrc`, as long as the line ignoring `export` statements
remains. Why can't I `export` variables from these scripts?
Replying to [comment:8 mankoff]:
> I'm not clear how the comment in `grass.py` pointing to this ticket
helps. Certain critical environment variables that are **required** for
GRASS to work correctly cannot be set in either `~/.grass.bashrc` or
`~/.grass7/bashrc`, as long as the line ignoring `export` statements
remains. Why can't I `export` variables from these scripts?
As I mentioned earlier, the environment variables should be loaded by
`load_env()`. I tested your config file and it's working on my Linux
machine. So probably something related to MAC? Try to put more debug
message around `load_env()`.
Yes this is something MAC related. The Fink installation of GRASS gets
around this by modifying the program to look for a `GRASS_LIBRARY_PATH`
which lets me set the `DYLD_LIBRARY_PATH`. I'm using MacPorts and this
modification has not been made.
I get that as mentioned earlier, environment variables should be loaded by
`load_env()`. But nobody has offered an explanation for why `export`
statements are ignored here. GRASS is, generally, a power user tool and
lets the users do what they want. Why is it acting in such a protective
manner here?
Results from running GRASS with `GRASS_DEBUG=ON` are:
{{{
$ GRASS_DEBUG=ON grass72 -c EPSG:3413 ./Gtmp
DEBUG: GRASS_DEBUG environmental variable is set. It is meant to be an
internal variable for debugging only this script.
Use 'g.gisenv set="DEBUG=[0-5]"' to turn GRASS GIS debug mode on if you
wish to do so.
DEBUG: Environmental variable set BAR=42
DEBUG: Environmental variable set
DYLD_LIBRARY_PATH=/opt/local/share/grass-7.2.2/lib
DEBUG: Tmp directory
'/var/folders/7y/lbz1bs057398tql00m7fz0hr0000gn/T/grass7-kdm-10348'
created for user 'kdm'
Cleaning up temporary files...
access: No such file or directory
ERROR: LOCATION </Users/kdm/Gtmp> not available
Creating new GRASS GIS location/mapset...
DEBUG: Mapset </Users/kdm/Gtmp/PERMANENT> locked using
'/Users/kdm/Gtmp/PERMANENT/.gislock'
Welcome to GRASS GIS 7.2.2
GRASS GIS homepage: http://grass.osgeo.org
This version running through: Bash Shell (/bin/bash)
Help is available with the command: g.manual -i
See the licence terms with: g.version -c
See citation options with: g.version -x
Start the GUI with: g.gui wxpython
When ready to quit enter: exit
DEBUG: GRASS GUI should be <text>
.grass.bashrc
.grass7/bashrc
GRASS 7.2.2 (Gtmp):~ > env | grep BAR
BAR=42
GRASS 7.2.2 (Gtmp):~ > env | grep DY
GRASS 7.2.2 (Gtmp):~ >
}}}
> I get that as mentioned earlier, environment variables should be loaded
by `load_env()`. But nobody has offered an explanation for why `export`
statements are ignored here. GRASS is,
Well, then it's up to you to help us discovering where the problem is.
Nobody else was able till now to reproduce this bug. Than it's hard to
guess.
> generally, a power user tool and lets the users do what they want. Why
is it acting in such a protective manner here?
Instead of hacking around it would be nice to find out why `load_env()` is
not working in your case.
{{{
> $ GRASS_DEBUG=ON grass72 -c EPSG:3413 ./Gtmp
> DEBUG: GRASS_DEBUG environmental variable is set. It is meant to be an
internal variable for debugging only this script.
> Use 'g.gisenv set="DEBUG=[0-5]"' to turn GRASS GIS debug mode on if you
wish to do so.
> DEBUG: Environmental variable set BAR=42
> DEBUG: Environmental variable set
DYLD_LIBRARY_PATH=/opt/local/share/grass-7.2.2/lib
}}}
For some reason, all of this "security" can easily be bypassed if the
GRASS startup script does not explicitly block `export` statements as in
the attached patch.
To try to clarify/summarize the above comments: OS X has a security
feature that makes `load_env()` not work properly, and therefore the
temporal framework is not available to OS X users. There is a simple work-
around: Remove one line in the startup script. Patch is attached.
There may be other ways to fix this bug, but I have not yet discovered
them, and the proposed fix is simple and has no downsides that I can see
or that anyone has mentioned in the comments.
I have asked but not received an explanation for why this line exists in
the startup script. The offending line blocks users from `export`'ing
environment variables in `~/.grass7/bashrc`. This decision confuses me -
GRASS is a power-user tool, and anyone setting environment variables there
presumably knows what they are doing.
Replying to [comment:15 mankoff]:
> I have asked but not received an explanation for why this line exists in
the startup script. The
sorry, but you got an explanation! Please read carefully the comments.
There is a special procedure for loading environmental variables
(``load_env()``). That's reason why this line exists in the code.
Anyway I will prepare patch for security issue reported in MacOS. It will
be still workaround anyway.