bug: input filenames containing a dot are not parsed correctly

[herrsimon]

Hello,

I think that I just encountered a bug: If the input filename contains a dot but does not not have a 'bib' extension, then bibtool does not read it correctly. In other words, if test.bib and test.abcde have identical contents and some_resource.rsc yields some output, then

bibtool -r some_resource.rsc -i test.bib -o test2.bib

works as expected (output is written to test2.bib), whereas

bibtool -r some_resource.rsc -i test.abcde -o test2.bib

results in test2.bib being empty.

The -o argument does not have this problem.

[ge-ne]

Sorry, I am not able to reproduce this observation. I have tried it in an empty directory containing just some_resource.rsc (empty) and test.abcde (with an @article). The result appears in test2.bib.

The effect you encountered must have to do with something else...

[herrsimon]

Thanks for the quick reply, I did another test with exactly the same setup as you (empty resource file, just one @article in test.abcde) and think I found the problem: Now I get *** BibTool WARNING: File test.abcde not found (which was not printed before as I was using bibtool inside some script), with nothing written to test2, and in fact this warning appears for any input filename unless it either ends in .bib or another file with the same basename and .bib appended exists in the current directory. Then I ran bibtool -V and saw that my binary was compiled with the kpathsea option, which seems to be responsible for this behaviour.

In your test, did you also use a version with kpathsea compiled in?

[ge-ne]

I have used a minimalistic setup for testing without kpathsea.

For kpathsea you can set the environment variable KPATHSEA_DEBUG, or instance to 1023, to gain some insight on the internals...