[GRASS-dev] GRASS init.sh

David Finlayson david.p.finlayson at gmail.com
Mon Jun 12 03:08:37 EDT 2006


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)
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.

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?

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

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).

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.

I see all of this mainly as an issue for making the code portable
across platforms and execution environments (such as my IPython
experiment). It would be easier to put configuration options in a
configuration file and then have the various shells pick up the data
using their available tools. I think that this would be much more
portable and much simpler as well.


-- 
David Finlayson




More information about the grass-dev mailing list