Opened 8 years ago

Closed 5 years ago

Last modified 5 years ago

#2679 closed defect (fixed)

Drop or fix setting of Location and Mapset using environmental variables

Reported by: wenzeslaus Owned by: grass-dev@…
Priority: normal Milestone: 7.6.0
Component: Startup Version: svn-trunk
Keywords: init,, interface, CLI, script, batch job Cc:
CPU: Unspecified Platform: Unspecified


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>
  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 wenzeslaus, 8 years ago

If this should be implemented, see #2681 for names of variables.

comment:2 by neteler, 7 years ago


Milestone renamed

comment:3 by neteler, 6 years ago


Ticket retargeted after milestone closed

comment:4 by martinl, 6 years ago


comment:5 by neteler, 6 years ago


Ticket retargeted after milestone closed

comment:6 by martinl, 5 years ago

Milestone: 7.2.3

Ticket retargeted after milestone closed

comment:7 by martinl, 5 years ago

Milestone: 7.2.4

comment:8 by wenzeslaus, 5 years ago

Resolution: fixed
Status: newclosed

In 72791:

init: remove broken env var interface for d/l/m

The interface described in the manual was not implemented and not part of --help.
It seems that it was broken at least since trans from Bash to Python (r37863)
and definitevely before refactoring in r65235. Perhaps some time after env vars
were definitevely removed from modules (r10655, r10790, r10793).

Closes #2679 (Drop or fix setting...) and see #2681 for more explanation
esp. about the unfortunate naming (LOCATION vs LOCATION_NAME).

This removes the only code which seemed to be really specific for
the grass - call and it removes a significat portion of the manual
which discusses usage and env vars and command line params priorities
in various combinations.

comment:9 by wenzeslaus, 5 years ago


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.

comment:10 by wenzeslaus, 5 years ago

In 73355:

init: replace obsolete doc by link to up-to-date doc (see #2679, r72791, r73354)

comment:11 by wenzeslaus, 5 years ago

Finished in r73355 and r73354 (linked to a wrong ticket).

Note: See TracTickets for help on using tickets.