[Xastir] DBFAWK - Doin' it wrong?

[Tom Russo]

On Tue, Mar 24, 2020 at 08:28:08AM -0500, we recorded a bogon-computron collision of the <kg4wsv at gmail.com> flavor, containing:
> On Mon, Mar 23, 2020 at 7:28 PM Chip Griffin <n1mie at mac.com> wrote:
> 
> >  the results of the DBFAWK are not equal.
> >
> 
> Could there be an additional dbfawk on the system that is not behaving as
> expected?
> 
> It's possible to hove more than one dbfawk that matches a particular file.
> I beat my head against the wall for a short time trying to figure out why
> my dbfawk wasn't working as expected when the reason was that another
> dbfawk (in my case one that came with xastir) was kicking in first.

Oooh.  Yeah, that's another way it could happen.

> I do not recall the logic of how a dbfawk is selected when there are
> multiple files that match the dbf signature.

If there is a per-file dbfawk that matches the file's name (e.g. if 
you've got foo.dbf and foo.dbfawk exists, it is used).  Otherwise, the first
one that matches the signature is used.

However, the "first one that matches" is the first one in a linked list of
pre-scanned dbf signatures, which is constructed by repeatedly making
"readdir" calls on the config directory and scanning the files it finds.  
That probably means that the file that comes first lexicographically.

The surest way to check whether this is happening is to copy your dbfawk
to have the same name as the dbf file you want it to match, and put it in
the same directory as the dbf file.  If the rendering changes, this is the 
problem and then you have to find the other file in the config directory
that has the same dbfinfo line.

Alternatively, rename your dbfawk file with "AAAA" as a prefix so it comes
first in the readdir loop.  Either way, if the rendering changes, Jason's
issue is the one that's your problem.

-- 
Tom Russo    KM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]