[GRASS5] Questions regarding GIS.sh

Justin Hickey jhickey at impact1.hpcc.nectec.or.th
Mon Jul 3 12:31:31 EDT 2000


Hello all

As you may know, I am creating a new interface for the startup routines of
GRASS in Tcl/Tk. At the same time I would like to clean up some of the existing
code. Since I am not that familiar with sh script programming, my initial
investigation has led to some questions that I would like to pose to the list.
I would appreciate any answers to the following questions. Note that the file
etc/GIS.sh is created from three files in src/general/gis, namely gis.head,
gis.shell, and gis.tail

1. In gis.head the user's home directory is determined by
	home=`cd;pwd`
   Is it safe to assume that this information can be obtained from the $HOME
   environment variable? It seems to me that the $HOME variable is guaranteed
to
   exist on all platforms. Is there any reason not to use it?

2. In gis.head the path is set to the GRASS bin directory and also the garden
   bin directory. Why do we have a garden bin directory? Why are these binaries
   kept separate from the other binaries? By default, nothing is compiled into
   this directory, so why is it there? BTW, why is it named "garden" in the
   first place? It is not a very intuitive name to me.

3. In gis.head the following line is used to unset the MONITOR variable
	# unset the MONITOR variable to force user to select one if they are
	# going to do graphics.

	g.gisenv MONITOR=
   Why do we need to unset this variable? Is it simply to ensure that the user
   does not have a variable of the same name in their own environment? If so,
   then why don't we rename the variable to GRASS_MONITOR to ensure this is not
   the case?

4. In gis.head the following lines appear
	if [ -x $home/.grassrc5.VERSION_NUMBER ]
	then
		$home/.grassrc5.VERSION_NUMBER
	elif [ -x $GISBASE/grassrc5 ]
	then
		$GISBASE/grassrc5
	fi
   Markus has indicated that these files are there for historical reasons and
   should be able to be deleted. Is this true? Anyone know of a reason to keep
   them?

5. In gis.shell there is a trap statement to trap SIGINT and SIGQUIT, but these
   are ignored. Do we still need to ignore these signals? What was the original
   reason for ignoring them in the first place?

6. In gis.shell, for a csh or tcsh, the following line is set for the grass
   version of the .cshrc file
	echo 'set BOGUS=``;unset BOGUS' >> $cshrc
   What is the use of this? Why is this here? This does not appear for other
   shells. Also there are these lines that appear only for csh and tcsh users
	if [ -r $home/.cshrc ]
    	then
		grep '^ *set  *mail *= *' $home/.cshrc >> $cshrc
    	fi

    	if [ -r $home/.tcshrc ]
    	then
		grep '^ *set  *mail *= *' $home/.tcshrc >> $cshrc
    	fi

    	if [ -r $home/.login ]
    	then
		grep '^ *set  *mail *= *' $home/.login >> $cshrc
    	fi
   What are these for? Do we still need them anymore? Wouldn't it just be
easier
   to just put the users home settings at the first of the file and then put
the
   GRASS specific settings at the end of the file? That way, the user maintains
   his settings (aliases, etc) and any GRASS settings can override the users if
   necessary.

7. In gis.shell, the bash section has the following 2 lines
	echo "umask 022" >> $bashrc
    	echo "PS1='GRASS:\w > '" >> $bashrc
   Why do bash users have a umask, but no other shell users do? How does
   GRASS:\w actually set the prompt?

8. In gis.shell, all other shells set the prompt using
	PS1="
	Mapset <$MAPSET> in Location <$LOCATION_NAME>
	GRASS-GRID > "
   How does GRASS-GRID set the version number of GRASS?

9. It appears that src/libes/gis/env.c reads and writes to the .grassrc file
for
   most of its environment variables. I do not agree with this technique. For
me
   any .*rc file simply saves the environment that the program was in the last
   time the user used the program. This enables the program to be set into the
   last environment the next time the program is started. Therefore, the only
   time the .*rc file is accessed is to read in the previous environment at
   program startup, and then write the current environment at program shutdown.
   Thus, I propose to change env.c so that the only time the .grassrc file is
   accessed is during startup and shutdown. All other requests for environment
   variables will access the actual environment, not the .grassrc file. Does
   anyone know of any reason for not making this change?

Finally, a question totally unrelated to my project but it concerns something I
came across in my investigations. There are a couple of strange directory names
in the tree. etc/paint/driver.sh and src/imagery/i.tapes.mss.h These names
appear to be files but they are actually directories. Is there any reason for
this? It does seem strange to me since one looks like a shell script and the
other looks like a header file.

Anyway, if anyone can help answer these questions, it would be greatly
appreciated. Thank you for your time.

-- 
Sincerely,

Jazzman (a.k.a. Justin Hickey)  e-mail: jhickey at hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do.  ---Anonymous

Jazz and Trek Rule!!!
==================================================================

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list