Hi,
does this have to do with parsing the vector/$MAP/dbln file?
There was an unfortunate thing in the 6.x format spec of that file where
space was used as the delimiter and it was impossible to fix for spaces
in the path, since the result would always be ambiguous. In GRASS 7 I
changed the delim to '|', and AFAIR backported read-support for that back
to grass6. If that sounds like the issue let me know and I'll dig out
more details about it, and how to work around it so it works cleanly
in all branches in a backwarks-forwards compatible way.
Note that for the dbln file the C code looks for and substitutes for
$GISDBASE/$LOCATION_NAME/$MAPSET/
on all platforms, they are simulated enviro variables and for file-
system portability should be kept in the above form instead of replacing
with a real path. (unless that's really what you want to do)
I recently added the fs parameter to be able to open data
which contain | character by changing the separator in
preferences.
sorry, this email thread got lost in the pile. where/what specifically
are you talking about there?
Hamish
[sorry for the top posting, broken linewrap, and missing authors, too
late to fight with yahoo tonight]
> when loading "roadsmajor" of NC on various windows
machines (with
> and without white space in the grassdata path, we get
>
> Error:
> 'columns' is not recognized as an internal or external
command,
> operable program or batch file
> [OK]
>
> Then the attrib. manager opens but it remains empty.
>
> Maybe here?
>
> dbmgr/manager.py
> ...
>
self.listOfCommands.append(('v.db.addcol',
>
{ 'map' :
self.vectorName,
>
'layer' :
self.layer,
>
'columns' : '%s %s' % (name,
ctype) }
>
))
>
> No idea..
>
> Markus
Problem occurs when calling this (line 194, dbmgr/manager.py
in grass64)
ret = RunCommand('v.db.select',
quiet = True,
parent = self,
flags = 'c',
map = self.mapDBInfo.map,
layer = layer,
columns = ','.join(columns),
fs = fs,
where = where,
stdout = outFile)
I recently added the fs parameter to be able to open data
which contain | character by changing the separator in
preferences. On
Windows it is causing splitting the whole command into 2
parts -
before and after pipe. As a result 'columns' parameter
(after pipe) is
treated like another command. As a temporal workaround you
can set the
separator to something different in preferences (more
characters are
accepted) - this should work immediately. I can also
revert the
change.
On Linux the characters in parameters are escaped properly
probably in
Popen but not on Windows. Anyone knows how to solve this
properly?