[GRASS-dev] GISDBASE directory name with spaces

Glynn Clements glynn at gclements.plus.com
Wed Oct 18 07:14:58 EDT 2006


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.

It won't handle a path which *begins* with a space, but that's
unlikely.

It won't handle a path which contains an embedded newline either, but
that's:

a) even more unlikely,
b) not a valid path on Windows, and
c) an inherent limitation of using a newline as the record separator.

Note that Tcl opens files in text mode by default, so we don't have to
worry about trailing CR characters if $GISBASE contains CRLF line
terminators.

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




More information about the grass-dev mailing list