[GRASS-dev] GRASS init.sh

[Glynn Clements]

David Finlayson wrote:

> It seems to me that the GRASS initialization script is a lot more
> complicated than necessary. If I understand correctly, the script
> needs to do seven things:
> 
> 1. Set the system environment variables (GISBASE, PATH, LD_LIBRARY_PATH, etc)
> 2. Set the user environment variables (GISDBASE, LOCATION_NAME, MAPSET, etc)

To be precise, these aren't environment variables. Within Init.sh,
they are just shell variables (they aren't exported). Init.sh writes
the values to $GISRC, and all GRASS modules obtain the settings from
there.

[Historically, Init.sh used to export them so that they could be
accessed easily from within shell scripts. However, that has the
drawback of making g.mapset (and similar) impossible to implement, as
a command can't change the environment of the shell.]

> 3. Create a temporary directory for processing
> 4. Copy .grassrc6 into the temporary directory for session use
> 5. Launch a Shell with the GRASS environment variables set
> 6. Copy the session grassrc file from temporary directory back to .grassrc6
> 7. Delete the temporary directory
> 
> Seems straight forward until you take a look at the scripts involved.
> A few issues:
> 
> 1. system-wide environment variables are embedded in two different
> scripts (grass61, $GISBASE/etc/init.sh) instead of in a (single)
> system-wide configuration file.

The only environment variable set in grass61 is GISBASE. That has to
be set there because the rest of GRASS (including Init.sh) is
referenced relative to $GISBASE.

> 2. Many system-wide environment variables are determined at run-time
> by init.sh. This means that there is a lot of platform specific code
> looking for libraries and executables. Routines are different for each
> shell and each major platform. Surely there is a better way to do
> this? Maybe a configuration wizard that helps the user write or update
> their system-wide config file?

Different users may have different values for $SHELL and $PATH. 
Init.sh needs to work for all users, not one specific configuration.

> 3. user environment variables are stored in two places $HOME/.grassrc6
> and $HOME/.grass.$SHELL

~/.grassrc6 contains GRASS variables, not environment variables, while
~/.grass.$SHELL contains environment variables.

> 4. Again, there is a lot of code in init.sh that tries to discover
> these user variables and if necessary query from the user (including a
> crude, text-based gui in the script itself).

Nothing is set from user input; the "read ans" commands are only used
to wait for a keypress; there are no references to $ans in the script.

> 5. Of course, this won't run at all on Windows without a full Unix
> emulation layer
> 
> 6. It's written in sh, it looks like line noise.

Those last two are valid points. The question is, what language /will/
work on all common platforms?

Regarding point 5, there is still a /lot/ of stuff in GRASS which
assumes a Unix shell and common tools. Look[1] for calls to system(),
and the commands which are being run. Until there has been substantial
progress in fixing those issues, there isn't much point in worrying
about Init.sh. In the worst case, we can just provide an equivalent
Init.bat script for Windows users.

[1] The obj_imp table in the database created by tools/sql.sh is the
easiest way to locate calls to specific functions.

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