#2679 closed defect (fixed)
Drop or fix setting of Location and Mapset using environmental variables
Reported by: | wenzeslaus | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.6.0 |
Component: | Startup | Version: | svn-trunk |
Keywords: | init, grass.py, interface, CLI, script, batch job | Cc: | |
CPU: | Unspecified | Platform: | Unspecified |
Description
The manual describes that one can set Location and Mapset using system environmental variables but it does not work:
$ export GISDBASE=~/grassdata/ $ export LOCATION_NAME=nc_spm_08_grass7_tests_2 $ export MAPSET=landsat $ .../grass71 - Cleaning up temporary files... Starting GRASS GIS... Traceback (most recent call last): File ".../grass71", line 1423, in <module> non_interactive(args[0]) File ".../grass71", line 586, in non_interactive if gisdbase and location_name and mapset: NameError: global name 'gisdbase' is not defined
I was wondering if I broke it but I get this behavior in r65235 before any changes I made. It actually seems that is was always broken since r37863, translating from Bash to Python.
This means that nobody is using with 7 it because nobody complains. For now I just put pass
in to that if
branch (it will fail later).
Also the dash used in this context seems quite strange, especially for GRASS. We should consider alternatives.
In general this behavior seems useless to me, why use environmental variable when I can use parameter? However, it might become quite useful with the "exec subcommand" (#2579) for running commands inside the session. You would set the environment and then just call grass:
export GISDBASE=~/grassdata/ export LOCATION_NAME=nc_spm_08_grass7_tests_2 export MAPSET=landsat grass7 - exec g.region -p
Do we want to restore this behavior or it is ok to drop it?
If we want to fix also 7.0, some copy & paste should be possible.
PS: Either way, I won't be able to work on it right now, so if somebody can take over, it would be great. (It should be much easier now after the refactoring. There are notes in the source code about what needs to be done.)
Change History (11)
comment:1 by , 10 years ago
comment:4 by , 8 years ago
Milestone: | 7.2.1 → 7.2.2 |
---|
comment:7 by , 7 years ago
Milestone: | → 7.2.4 |
---|
comment:9 by , 6 years ago
Milestone: | 7.2.4 → 7.6.0 |
---|
Glynn comment:3:ticket:2681:
So then I would say that if #2679 functionality will be implemented (rather then dropped)...
I see no reason to implement it. And if it is implemented, the startup script should explicitly remove those variables from the environment.
I agree that the current (currently documented) behavior is not useful in the way it is. Of course, the code to make it work is not really there in the first place. If this should be ever implemented again, probably a dedicated flag (like -e
or --env
) should be used and the variables should be named GRASS_MAPSET
etc.
This functionality seems to be working in 6.4. If it is useful for your use case, please open another ticket to add it to 7.x or 8.
If this should be implemented, see #2681 for names of variables.