I don't think the whitespace in GISDBASE is a big problem any
more for us, hopefully with 6.4.3 we'll get rid of the last
of the quoting problems-- the strategy of not ignoring the
problem seems to have worked well to front-load the errors
instead of having them drift in over the next many years.
It is also good that any quoting errors get fixed for all
versions of GRASS, as spaces (and especially other chars) in
path names are perfectly valid in Linux and Mac. ie thanks to
WinGrass for highlighting them, now we have more solid code
everywhere.
The big problem is MSys, who refuse to accept patches fixing
spaces in pathnames issues, and even so far a patch to exit
with a nice error message instead of crashing out later in
their startup script with a bash error. (we patch that file
locally to work; in spite of their doubts so far everything
in the GNU tools seems ok at run-time.. [except autoconf,
builds of grass from source code still need to happen in
space-free paths] I'd argue that it is especially important
to fix the GNU tools since they are used everywhere and
bugs in them could lead to injection attacks and other nasty
stuff on important servers they run on. But I digress
as to your second point of "is different from most GRASS
tutorials", I agree, and it keeps the confusing "database"
double definition out of it.
for another thread: how to annotate that the <div class="code">
EXAMPLES which use Bourne shell loops and line continuations\
require special care to be used in wingrasses or the wxGUI
command line? I don't think just getting rid of them all is
a good solution.
>> while playing with winGRASS on Windows 8, I realized that
>> the default grassdata path is a bit unfortunate:
>>
>> grep 'GIS Data' */* 2>&1 | grep -v directory
>> mswindows/GRASS-Installer.nsi.tmpl:
>> StrCpy $GIS_DATABASE "$DOCUMENTS\GIS DataBase"
>>
>> - uses white space (which we commonly dislike)
>> - is different from most GRASS tutorials
>>
>> Why not
>>
>> StrCpy $GIS_DATABASE "$DOCUMENTS\grassdata"
>>
>> which would solve above problems?
>
> I don't think the whitespace in GISDBASE is a big problem any
> more for us, hopefully with 6.4.3 we'll get rid of the last
> of the quoting problems
I still think that *asking* for problems is not a good strategy.
Both "$DOCUMENTS\GIS DataBase" and "$DOCUMENTS\grassdata" may contain
spaces, as $DOCUMENTS may contain spaces, and we can't do anything
about that.
The former is consistent: it will always contain spaces. The latter
may or may not contain spaces, meaning that particular changes may
work for the developer making the changes but not work for a
significant proportion of users.