[GRASS-dev] [GRASS GIS] #2681: Remove legacy meaning of LOCATION variable

GRASS GIS trac at osgeo.org
Wed May 20 05:45:41 PDT 2015


#2681: Remove legacy meaning of LOCATION variable
-------------------------+-------------------------------------------------
  Reporter:  wenzeslaus  |      Owner:  grass-dev@…
      Type:  task        |     Status:  new
  Priority:  blocker     |  Milestone:  8.0.0
 Component:  Startup     |    Version:  svn-trunk
Resolution:              |   Keywords:  init, grass.py, interface, CLI,
       CPU:              |  environment variables
  Unspecified            |   Platform:  All
-------------------------+-------------------------------------------------

Comment (by glynn):

 Replying to [ticket:2681 wenzeslaus]:

 > Especially in older and stable code like `grass.py` we still keep the
 legacy `LOCATION` variable with meaning "full path to a Mapset".
 >
 > The bug #2679 suggests that nobody is actually using it. So, there is no
 need for keeping this for backward compatibility anymore.

 Originally, GISDBASE, LOCATION_NAME and MAPSET were actual environment
 variables. Even after G_getenv() etc were added, the startup script
 continued to set the environment variables for the benefit of scripts.
 When g.mapset was added, we had to change scripts to explicitly query the
 environment using g.gisenv, because g.mapset cannot change the environment
 variables of its parent process (e.g. the shell). To ensure that this was
 done, the startup script stopped setting the environment variables
 (r10655), so that unfixed scripts failed rather than using a possibly-
 incorrect environment. The export for LOCATION was re-added temporarily in
 r10790 then removed again in r10793.

 None of these variables should have been exported to the environment in
 over a decade.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2681#comment:1>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list