Markus Neteler wrote:
I have commited some changes to CVS to support white space
to some extend.
GRASS:/tmp/grass data > g.gisenv
GISDBASE=/tmp/grass data
LOCATION_NAME=rmapcalcUTM
MAPSET=PERMANENT
MONITOR=x0
GRASS_GUI=text
GRASS:/tmp/grass data > pwd
/tmp/grass data
GRASS:/tmp/grass data > l
total 4
drwxr-xr-x 3 neteler ssi 4096 Feb 27 16:12 rmapcalcUTM
GRASS:/tmp/grass data >
It's possible to start GRASS now with white spaces.
But is it possible to use it? If it isn't, it might be better if GRASS
simply refused to start.
Also, in most of the cases where users have had problems due to
whitespace, the problem has been due to their home directory rather
than GISDBASE. This is arguably a more serious problem, as the user
can choose where to put GISDBASE, but they don't necessarily get to
choose their home directory.
Hope that it doesn't break anything,
but the changes are just variable quoting in the start shell
scripts.
I suspect that many shell[1] scripts will be broken for similar
reasons. Similarly for anything which passes to system() or popen()
any filenames which are within GISDBASE.
For system() etc, use single quotes, e.g. change:
sprintf(buff, "command %s", filename); system(buff);
to:
sprintf(buff, "command '%s'", filename); system(buff);
This should handle any filename except one which contains a single
quote character (which is pretty unlikely). Ultimately, use of
system() should be eliminated.
[1] Tcl/Tk mostly[2] avoids the problem, as it performs tokenisation
(splitting the string into words) before it expands variables; when a
variable is expanded to its value, the result remains a single token
even if it contains whitespace.
[2] However, using a variable within a double-quoted string which is
subsequently tokenised (e.g. eval "...", open "|...") will have the
same problem.
--
Glynn Clements <glynn.clements@virgin.net>