[GRASS-dev] GRASS init.sh

[Glynn Clements]

David Finlayson wrote:

> > GRASS doesn't have any configuration files. Everything which can be
> > configured is done so through the environment.
> 
> ...and set dynamically mostly at run time, that is my point.

Many of the ones set by Init.sh are only set if they aren't already
set on entry. IOW, the settings in Init.sh are fall-back settings if
the user hasn't made an explicit choice.

> In the
> future (GRASS 7) it would be nice to move the configuration
> information currently stored in 34 environment variables (see:
> http://grass.itc.it/grass61/manuals/html61_user/variables.html) to a
> configuration file.

Environment variables have the advantage that each process has a
separate environment, so you can change the settings on a per-process
basis.

Many of the variables listed on the page which you reference are only
intended to be used that way. I.e. they are not meant to be set in the
environment of the session shell, but set locally for individual
commands.

> That way new shells could get the info without
> needing to recreate the do-it-all initialization process that init.sh
> goes through in GRASS 6.X.

Very little of Init.sh is shell-specific; note that the default case
only sets PS1.

Most of the shell-specific stuff amounts to hacks which someone
thought would be a good idea but aren't entirely necessary (e.g. 
setting $HOME to the mapset directory then making the shell's startup
script set it back, so that the history gets written to the mapset
directory rather than to the default history file).

> I am pretty close to having most of GRASS running entirely in a Python
> shell. The only thing Python needs to know are what environment
> variables to set up. It does this the same way on Mac, Windows and
> Unix, so I don't need all of the platform specific code that is
> currently in init.sh and I MUST export it somehow so that Python can
> read it. I would like the user to be able to run the Python version or
> traditional grass using a common configuration file so that the user
> only needs to change it in one place when updating things.

The environment variables which matter are:

PATH
LD_LIBRARY_PATH [*]
GRASS_LD_LIBRARY_PATH
GISBASE
GISRC
GIS_LOCK
GRASS_HTML_BROWSER
GRASS_PAGER
GRASS_PERL
GRASS_TCLSH
GRASS_WISH
GRASS_VERSION
TCLTKGRASSBASE

Obviously, PATH needs to be set relative to $GISBASE so that GRASS
commands and scripts can be executed without having to provide an
absolute path.

LD_LIBRARY_PATH is actually a platform-specific variable; see the
rules for $(ETC)/Init.sh and $(ETC)/grass-run.sh in lib/init/Makefile.

The value for LD_LIBRARY_PATH_VAR is set by the SC_CONFIG_CFLAGS
autoconf macro in aclocal.m4. You will need to get this into your
Python script (unless Python provides a portable interface for this).

GRASS_LD_LIBRARY_PATH has to be set to the same value; this is used by
grass-run.sh to restore the library search path in case it is cleared
by the loader (which happens if you run a setuid/setgid program such
as xterm).

There needs to be a script installed into the system binary directory
(e.g. /usr/local/bin) which does nothing more than set GISBASE to a
specific value then call the main initialisation script from within
$GISBASE. Nothing under $GISBASE has the installation location
hard-coded in, so if you want to install a new version without
removing or disabling the old version, you can just move or rename the
installation directory and modify the grass61 script to match.

GISRC needs to contain the pathname of a writable file which contains
valid settings for GISDBASE, LOCATION_NAME, MAPSET and GRASS_GUI. How
you create this file and where you store it is up to you, but you need
to allow for multiple GRASS sessions, each with a separate state file
(Init.sh puts it in a directory whose name includes the PID).

GIS_LOCK needs to contain the PID of the Init.sh script (at least, it
needs to contain the PID of one of the processes comprising the
session). The FIFO transport for the display drivers create lock files
which contain the PID (so that they know which session created the
lock file).

The various GRASS_* variables are used to specify particular programs,
except for GRASS_VERSION which is (apparently) used by the R
interface.

TCLTKGRASSBASE is probably a misfeature; Tcl code which uses it could
just use $GISBASE/etc instead.

Of the others used in the Init.sh script, GISRCRC shouldn't be
exported, PAGER doesn't need to be mentioned in the script (it will
get passed on to the shell automatically), and GRASS_GNUPLOT is no
longer used (the modules which used it aren't present in 6.x).

-- 
Glynn Clements <glynn at gclements.plus.com>