Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#571 closed defect (fixed)

v.db.addcol: fails if path contains spaces

Reported by: pcav Owned by: grass-dev@…
Priority: normal Milestone: 6.4.0
Component: Default Version: unspecified
Keywords: Cc:
CPU: Unspecified Platform: Unspecified


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, now submitted to grass upon suggestion by rblazek

Attachments (1)

v.db.addcol_63.diff (1.3 KB ) - added by neteler 15 years ago.
GRASS 6.3 v.db.addcol patch for white space

Download all attachments as: .zip

Change History (10)

comment:1 by neteler, 15 years ago

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):~ > -c myrailroads 
Displaying column types/names for database connection of layer 1:
DOUBLE PRECISION|LENGTH                                          

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.

comment:2 by hamish, 15 years ago

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:

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?


comment:3 by pcav, 15 years ago

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 from

comment:4 by hamish, 15 years ago

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.


comment:5 by pcav, 15 years ago

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 >

comment:6 by mlennert, 15 years ago

Resolution: fixed
Status: newclosed

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.


by neteler, 15 years ago

Attachment: v.db.addcol_63.diff added

GRASS 6.3 v.db.addcol patch for white space

comment:7 by neteler, 15 years ago

Paolo, can you please try attached patch?

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


in reply to:  7 comment:8 by mlennert, 15 years ago

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 ?


comment:9 by neteler, 15 years ago

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


Note: See TracTickets for help on using tickets.