#809: v.db.addtable consistently fails in winGrass ------------------------------+--------------------------------------------- Reporter: JonBall | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Vector | Version: svn-releasebranch64 Resolution: | Keywords: v.db.addtable, wingrass Platform: MSWindows Vista | Cpu: x86-64 ------------------------------+--------------------------------------------- Comment (by hamish):
Hamish: > hmm, there is still a quoting bug in v.to.db called by > v.db.addtable: ... > ah, here we go: Line 634 of lib/vector/Vlib/field.c scanning > the dbln file does not like spaces in the db path string- > {{{ ndef = sscanf(buf, "%s %s %s %s %s", fldstr, tab, col, db, drv); }}} > note you have to be using layer 2 or greater to see this. I'm guessing G_tokenize(buf, ' ') + the same approach taken by the wxGUI for this some weeks ago and pull off db as tokens 4 to (ntok-1) and then drv with the last of G_number_of_tokens()? I suppose a similar thing could be done with strrchr() to chop the drv off the string first, set strrchr() to '\0', then to get db go back and read {{{ %[^\n] }}} to the end of the remaining line? any recommendations from C string parsing experts? Replying to [comment:8 mmetz]: > I think this is a bug. v.db.addtable should always use the > default, unparsed database connection settings because there > is no database option in v.db.addtable. note that layer 2 parsing is done by libvect (called by v.to.db) doing the damage here as it scans through the layers, if the shell script does expansion or not, it is more general & will fail with any dbln with a space in the path. the script expansion just makes this bug be triggered more often. {{{ # finally we have to add cats into the attribute DB to make modules such as v.what.rast happy: # (creates new row for each vector line): }}} what you mention here is a secondary "feature" (which probably doesn't help) who's main draw back is that it makes the vector map less portable. > If a table already exists in layer 1 and a new table is to > be added for another layer, v.db.addtable uses the definition > for layer 1 as returned by v.db.connect -g which parses > "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/". Suggested fix would be > to always use the default unparsed database connection, > i.e. skip the check in v.db.addtable lines 119 - 136 (grass64). hmmm ok; {{{ g.copy v=roads,myroads v.db.addtable myroads layer=2 col="left integer, right integer" dbln: 1 myroads cat $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbf 2 myroads_2 cat /home/hamish/grassdata/spearfish60/user1/dbf/ dbf }}} if a layer 1 exists* it uses the default mapset/VAR values from db.connect, see lines 124-125 and 131-132. it only reuses (&expands) layer 1's DB path definition on line 128. A secondary question is should the new layer prefer to use the mapset's default DB or the map's existing layer 1 DB? I don't know the answer to that, I think we just have to pick one. Is there a command print the unexpanded version or do we just resort to raw parsing of the dbln file to get it? [*] (is it possible for there to be no layer 1 but do have a layer >1? if so will that cause problems for this script?) Hamish -- Ticket URL: <https://trac.osgeo.org/grass/ticket/809#comment:9> GRASS GIS <http://grass.osgeo.org>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev