v.db.addcol: fails if path contains spaces

[pcav]

When adding a column, if the path to the dbf (possibly this is true also for other DB drivers?) contains spaces), the command fails. First found on QGIS ​https://trac.osgeo.org/qgis/ticket/1632, now submitted to grass upon suggestion by rblazek

[neteler]

You didn not specify the operating system.

On Linux, I cannot reproduce the problem:

GRASS 6.5.svn (nc_spm_08):~ > g.copy vect=railroads,myrailroads --o
Copy vector <railroads@PERMANENT> to current mapset as <myrailroads>

GRASS 6.5.svn (nc_spm_08):~ > v.db.addcol myrailroads col="test integer"

GRASS 6.5.svn (nc_spm_08):~ > v.info -c myrailroads 
Displaying column types/names for database connection of layer 1:
INTEGER|cat                                                      
INTEGER|OBJECTID                                                 
INTEGER|FNODE_                                                   
INTEGER|TNODE_                                                   
INTEGER|LPOLY_                                                   
INTEGER|RPOLY_                                                   
DOUBLE PRECISION|LENGTH                                          
INTEGER|RR24_100_                                                
INTEGER|RR24_100_I
INTEGER|MAJOR1
INTEGER|MINOR1
INTEGER|SCALE
INTEGER|test

GRASS 6.5.svn (nc_spm_08):~ > v.db.connect -p myrailroads
Vector map <myrailroads@neteler> is connected by:
layer <1> table <myrailroads> in database </home/neteler/grass data/nc_spm_08/neteler/dbf/> through driver <dbf> with key <cat>

The v.db.addcol code is identical to 6.4.0svn. Also the DBF driver is identical.

[hamish]

I can not reproduce this using Colin's latest standalone WinGRASS 6.4.0rc4+ installer (r36903), or on linux.

GISDBASE is in "Documents and Settings" so lots of spaces there.

Only problem I saw using the same commands as Markus (but from the wxGui) was that v.db.addcol exited with a helpful error message complaining that the table didn't exist and you should use v.db.addtable first, which I then did & reran v.db.addcol successfully. I guess that Markus is using the NC dataset and I'm using spearfish, which will explain why his already has a table and mine doesn't.

to repeat Markus's question: what OS? ms-windows?

you are trying to run this using the qgis-1.0 grass plugin, yes? Trying the latest OSGeo4W version 1.0.1:

• open toolbox to spearfish/user1 mapset
• copy over railroads to myrailroads
• v.db.addcol: complains there is no table, ok.
• v.db.addtable: [Run] "Warning: Name of new attribute table (defaut: ve ... : missing value"

even though in the script it says "#% required : no" for that option. (expands to "default: vector map name")

I seem to recall that the qgis-grass plugin has problems with empty options some time. e.g. problem 2b here:

​http://trac.osgeo.org/qgis/ticket/1133

and if you try nviz there is no way to select <none> from the list of maps for optional parameters (e.g. 'color map' should default to none)

anyway, if I type in 'myrailroads' for the table name manually and hit Run v.db.addtable works ok, even line wrapping on on of the the Documents and Settings space in the output message. And if I then run v.db.addcol it also Successfully finishes.

So can't reproduce it there either.

what's you exact error message, version, etc?

Hamish

[pcav]

It does not work from the shell either:

GRASS > v.db.addcol map=incrociata@paolo layer=1 'columns=provina integer'

ERROR: value <due/paolo/dbf/> out of range for parameter <driver>

Legal range: ogr,odbc,sqlite,mysql,pg,dbf

the location is prova due: obviously it parses it incorrectly. GRASS 6.3.0.1~gfossit20090217-1 from debian.gfoss.it

[hamish]

what does "v.db.connect -p incrociata@paolo" say?

how about "db.connect -p"?

can you edit the script to make the shebang: '#!/bin/sh -x' and post the output?

I guess it is db.execute making that complaint. I notice "driver=${$driver}". does ${foo} act the same as "$foo"? ... but db.execute does not have an option list for the driver parameter so should not give you one. ?

hmmm, was [v.]db.connect set to use a hard pathname instead of including '$' chars?: '$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/' those should stay like $MAPSET and not be exapanded.

Hamish

[pcav]

GRASS > db.connect -p driver:dbf database:$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ schema: group: GRASS > v.db.connect -p incrociata@paolo Vector map <incrociata@paolo> is connected by: layer <1> table <incrociata> in database </home/paolo/Desktop/test/prova due/paolo/dbf/> through driver <dbf> with key <cat> GRASS >

[mlennert]

The OP uses 6.3 and in that version spaces weren't supported because of

database=`v.db.connect $GIS_OPT_MAP -g | grep -w $GIS_OPT_LAYER | awk '{print $4}'`
driver=`v.db.connect $GIS_OPT_MAP -g | grep -w $GIS_OPT_LAYER | awk '{print $5}'`

This has since (6.4+) been fixed through the use of the new fs= parameter in v.db.connect:

database=`v.db.connect $GIS_OPT_MAP -g fs=";" | grep -w $GIS_OPT_LAYER | awk -F ";" '{print $4}'`
driver=`v.db.connect $GIS_OPT_MAP -g fs=";" | grep -w $GIS_OPT_LAYER | awk -F ";" '{print $5}'`

So, closing the ticket as fixed. If you can reproduce with 6.4+, please reopen.

Moritz

[neteler]

GRASS 6.3 v.db.addcol patch for white space

[neteler]

Paolo, can you please try attached patch?

# start GRASS
cd $GISBASE/scripts/
patch -p2 < v.db.addcol_63.diff

Markus

[mlennert]

Replying to neteler:

Paolo, can you please try attached patch?

# start GRASS
cd $GISBASE/scripts/
patch -p2 < v.db.addcol_63.diff

AFAICT, fs= was introduced after 6.3, or ?

Moritz

[neteler]

You are right - I only checked for the -g presence. So please disregard the patch.

Markus