[GRASS-dev] GISDBASE directory name with spaces

[Glynn Clements]

Moritz Lennert wrote:

> >> Trying to help some colleagues working with wingrass, I noticed that if 
> >> the GISDBASE variable in .grassrc6 containes spaces (ex: GISDBASE: 
> >> /home/mlennert/GRASS/TEST DATA), the gui startup screen does not 
> >> recognize the directory and gives a warning: "Invalid database. Finding 
> >> first valid directory in parent tree". However, I can manually navigate 
> >> to the directory and GRASS starts normally.
> >>
> >> As many MS Windows users have spaces in their directory names, I 
> >> personally think that the startup screen code should be fixed to allow 
> >> spaces in the GISDBASE variable.
> > 
> > Agreed. AFAIK, it's generally accepted that failure to handle spaces
> > in file/directory names is considered a bug rather than an accepted
> > limitation.
> > 
> >> I imagine it probably is a "simple" 
> >> issue of quoting in line 64 of lib/init/gis_set.tcl:
> >>
> >> 63: if { [scan $thisline "GISDBASE: %s" env_database] } {
> >> 64:       set database $env_database
> > 
> > No, it isn't quoting; it's the way that the %s conversion works:
> > 
> >        s         The input field consists of all the characters up to the next
> >                  white-space character; the characters are copied to the vari-
> >                  able.
> > 
> > The above should be changed to use "regexp" instead, e.g. (untested):
> > 
> > 	if { [regexp -- {^GISDBASE: *(.*)$} $thisline dummy env_database] } {
> > 		set database $env_database
> > 
> > This will treat everything from the first non-whitespace character to
> > the end of the line as the pathname.
> 
> Yes, this works. Thanks.
> 
> Should this also be applied to location names ? mapsets ?

Location and mapset names aren't themselves allowed to contain spaces,
but the complete path to a location or mapset directory will contain
spaces if GISDBASE contains them.

> I do get the following in the terminal window (with GISDBASE = TEST DATA):
> 
> bash: test: /home/mlennert/GRASS/TEST: binary operator expected
> bash: test: /home/mlennert/GRASS/TEST: binary operator expected
> bash: test: /home/mlennert/GRASS/TEST: binary operator expected

That is due to this in lib/init/init.sh:

    echo "PROMPT_COMMAND='if test -d `g.gisenv GISDBASE`/`g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`/grid3/G3D_MASK && test -f`g.gisenv GISDBASE`/`g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`/cell/MASK ; then echo [Raster and Volume MASKs present] ; elif test -f `g.gisenv GISDBASE`/`g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`/cell/MASK ; then echo [Raster MASK present] ; elif test -d `g.gisenv GISDBASE`/`g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`/grid3/G3D_MASK ; then echo [Volume MASK present] ; fi'" >> "$bashrc"

There are a couple of things wrong with this:

1. The g.gisenv commands are evaluated when the echo command is run,
so the value of PROMPT_COMMAND written to the .bashrc file in the
mapset directory has the current GISDBASE/LOCATION_NAME_MAPSET values
hardcoded. If you switch location/mapset during the session, it will
still check the old mapset to determine the prompt.

2. It doesn't quote the computed path, resulting in the above errors.

Try changing it to this instead:

    echo 'PROMPT_COMMAND='\''if test -d "`g.gisenv GISDBASE`/`g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`/grid3/G3D_MASK" && test -f "`g.gisenv GISDBASE`/`g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`/cell/MASK" ; then echo [Raster and Volume MASKs present] ; elif test -f "`g.gisenv GISDBASE`/`g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`/cell/MASK" ; then echo [Raster MASK present] ; elif test -d "`g.gisenv GISDBASE`/`g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`/grid3/G3D_MASK" ; then echo [Volume MASK present] ; fi'\' >> "$bashrc"

Dealing with a 500+ character command string is messy enough that I've
turned it into a script (lib/init/prompt.sh, installed to
etc/prompt.sh) and changed the PROMPT_COMMAND setting to:

    echo "PROMPT_COMMAND=$GISBASE/etc/prompt.sh" >> "$bashrc"

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