#366 dbfawk parses last "loaded" column incorrectly
The last field listed in the dbffields variable in a dbfawk will be
parsed incorrectly, such that you can't use it to match records
when the dbfawk is executed.
Example:
I have a shp/shx/dbf map. The dbf contains COL1, COL2, COL3. I
create a dbfawk that contains dbfinfo="COL1:COL2:COL3";, and a
dbffields entry of "COL1:COL3" (this could be any set of columns).
When the map is loaded, any regexes based on COL3 will not
execute.
At dbfawk.c line 368, when finfo represents COL3, finfo->type will
be FTInvalid, and line 380 will print "COL3\n =??". Obviously, this
is incorrect, regardless of the field type, and won't match any
dbfawk instructions. The problem will occur with whatever column
occurs last in dbffields. I imagine the problem is rooted in splitting
and parsing from the dbffields variable, but haven't had a chance
to track it down yet.
Sincerely and 73,
John Laxson KCŘPZN
Logged In: YES
user_id=558678
I believe this patch will fix the problem. It trims the dbffields string at the
first occurrence of a newline, before splitting it at the colons.
Logged In: YES
user_id=607718
While I don't doubt that you're seeing this problem, this is
certainly as universal as you indicate. There are numerous
dbfawk files that make use of the final column loaded by
dbffields, and I use some of them every day --- I have yet
to see this problem crop up. There might be something
specific to your shapefiles and dbfawk file that expose this
problem.
Could you provide, in addition to the patch you've provided,
an example of a dbfawk file where this is happening, and a
shapefile that matches that dbfawk file? Probably best to
point at a web site where we can download such a thing
rather than attaching to the bug report.
Also, please describe your xastir build in a little more
detail --- i.e. what system you're on, what version of
shapelib and pcre you're using, etc.
Lastly, your patch is an old-style, non-context diff, which
makes it a touch harder to apply unless we're working
exactly on the same version of the source code you have ---
this is not always the case. "context" diffs (diff -c) are
better, and unified diffs (diff -u) are much better.
Your patch seems to fix the case wehre the dbffields value
has a newline in it --- which I don't think should be the
case under normal circumstances.
Logged In: YES
user_id=607718
Bad edit on my part: in my first sentence I meant to say
"NOT as universal". The "not" got deleted in a sloppy edit.
Logged In: YES
user_id=607718
I am unable to reproduce this on any shapefiles I have with
corresponding dbfawk files that use the last column of
dbfinfo or dbffields. In no case do I see a trailing
newline added in a way described in the original bug report.
Absent any other data, I am going to conclude that the real
problem is a dbf file with a newline in its field name ---
which would mean that the dbfinfo and dbffields used in the
dbfawk file should have newlines, too, or things won't match.
Marking this "works for me"
Logged In: YES
user_id=607718
I just found an issue with dbfawk file parsing that appears
to be the cause here: if the "dbffields" definition line is
not terminated with a semicolon, dbffields gets a \n and
space added to it for no apparent reason. The parser needs
to be tidied up to fix this.
The workaround is to make sure that all satements in dbfawk
files end with a semicolon:
BEGIN {
dbfinfo="blah:diblah:diblahblah";
dbffields="blah:diblah:diblahblah";
}
instead of
BEGIN {
dbfinfo="blah:diblah:diblahblah";
dbffields="blah:diblah:diblahblah"
}
It was clearly intended by the author of dbfawk that
statements be semicolon-delimited, but the parser isn't
enforcing it and does the Wrong Thing when they aren't.
Reopening the bug and accepting.
The bug is in not catching the syntax error in the dbfawk
file and doing the wrong thing with it, not in a mis-parsing
of the dbffields or dbfinfo variable.
The Xastir project no longer uses sourceforge for issue tracking and I am closing all open issues (all of which are very old).
If this issue is still important, please open a new one on https://github.com/Xastir/Xastir.