Skip to content

A glitch (???) in tools::texi2pf.

9 messages · Rolf Turner, Eric Berger, Achim Zeileis +2 more

#
I have found that tools::texi2pf() ignores changes to the *.bib file
unless the *.bbl file is removed prior to re-running tools::texi2pdf().
I have constructed a minimal reproducible example which is contained
in the attached file "mreprex.txt".

This *.txt file should be split into two files, mreprex.tex and
mreprex.bib.  (I wasn't sure whether *.tex and *.bib files would make
it through to the list.)

After doing the splitting, start R, execute

tools::texi2pf("mreprex.tex")

and view the resulting mreprex.pdf file.  Then edit mreprex.bib
and change (e.g.) the version number from "0.0-21" to "0.0-22".

Re-run tools::texi2pf("mreprex.tex") and view mreprex.pdf.  You will
see that it hasn't changed; the version number cited is still given as
0.0-21.  Now remove mreprex.bbl, re-run tools::texi2pf("mreprex.tex")
and view mreprex.pdf.  You will see that the version number is given as
0.0-22 as it should be.

Should this be considered a bug?  If so, what is the appropriate way of
drawing this to the attention of those who have the power to fix it?

Thanks.

cheers,

Rolf Turner
#
On Sat, 28 Aug 2021, Rolf Turner wrote:

            
This is how texi2pdf (or actually texi2dvi) from texinfo behaves. This is 
likely what tools::texi2pdf calles in your setup anyway. In short, 
texi2dvi considers the .bbl as input files to the .tex and does not remove 
them if they are available prior to calling texi2dvi.

Alternatives:

(1) You can always re-run everything. Then simply start with a clean 
directory and always use tools::texi2pdf(..., clean = TRUE). This cleans 
up all the files it has produced (except the .pdf). But it will preserve 
files left in the directory from previous runs.

(2) You can detect upstream changes, e.g., based on timestamps etc. Then 
the traditional approach would be to use a Makefile.

Best,
Z
#
On Sat, 28 Aug 2021 09:47:03 +0200
Achim Zeileis <Achim.Zeileis at uibk.ac.at> wrote:

            
Thanks.  I guess you're saying that it's a feature, not a bug. :-)

Well it's a feature that I intensely dislike, but that cuts no ice I'm
sure, and I'll just have to cope with it. I can easily build a local
function that will remove *.bbl before invoking tools::texi2pdf(),
and use that, rather than calling tools::texi2pdf() directly.

However I *really* believe that this is a bad feature, and is a Trap
For Young Players.  Hardly anyone knows what a *.bbl is or is for.
Users would expect that changing the *.bib file would change the
reference list in the output.  (I.e. that texi2pdf() would re-run
bibtex "under the bonnet", as the user would do if processing from the
OS command line rather than applying texi2pdf() from R.)

I wonder how many papers in the R Journal have errors in their
reference lists due to the fact that authors corrected the *.bib file,
reprocessed using texi2pdf() and did not notice that the error they
corrected had *not* been corrected in the *.pdf output?

cheers,

Rolf
#
As Achim wrote in point (2), Makefile is your friend.


On Sat, Aug 28, 2021 at 12:39 PM Rolf Turner <r.turner at auckland.ac.nz>
wrote:

  
  
#
On Sat, 28 Aug 2021, Rolf Turner wrote:

            
Also. But the main point is that it's a feature of texi2dvi from texinfo 
which is called by tools::texi2dvi(). Hence, if you want to raise this 
somewhere it would have to be with the texinfo maintainers.
The problem is that currently texi2dvi has no concept of judging whether 
the .bib or .bbl were modified last.
I don't know what the R Journal editors are doing but for JSS I'm cleaning 
such files up (repeatedly actually) before compiling the final PDFs.

Best,
Z
#
On Sat, 28 Aug 2021 12:49:04 +0300
Eric Berger <ericjberger at gmail.com> wrote:

            
Well, all I can say is that Makefile is *not* my friend; I have never
made its acquaintance and wouldn't know where to begin looking.

Would it be possible for you to provide a template/prototype Makefile
and give me some idea what to *do* with it?

cheers,

Rolf Turner
#
I can understand Rolf's concern. Make is a tool that is very helpful,
but also not trivial to learn how to make work. If a good Makefile
has been set up, then things are easy, but I've generally found my
skills limited to fairly simple Makefiles.

I would suggest that what is needed is a bit of modest collaboration
to set up a Makefile for dealing with this issue that has enough comments
so it is clear what Make will be doing. I suspect that in this case the
need is to remove the offending .bbl file and then run the tex*** operations.
Possibly the result is small enough to post in this thread. Anyone?

Cheers, JN
On 2021-08-28 9:14 a.m., Rolf Turner wrote:
#
It is a general "feature" of TeX that documents with tables of
contents, indices,
bibliographies, and so on, have to be "iterated to convergence".  A couple of
PhD theses came out of Stanford; the problem is in that which page one thing
goes on depends on where other things went, which depends on where the
first thing went... TeX users got accustomed to this, which meant that they
also tolerated similar things in outboard tools like bibtex.  You
could of course
run bibtex explicitly to recreate the .bbl file.

Frankly, the suggestion of patching texi2pdf to delete the .bbl file(s) seems
like the simplest way forward.
On Sun, 29 Aug 2021 at 01:25, J C Nash <profjcnash at gmail.com> wrote:
#
On Sat, 28 Aug 2021, Rolf Turner wrote:

            
In a Makefile you can declare "rules" for producing certain "target" files 
from "prerequisite" files. The rules are only applied if any of the 
prerequisite files have changed since the target was last produced.

In your case the .bib is a prerequisite for the target .bbl which in turn 
is a prerequisite (along with the .tex) for the .pdf.

A nice introduction to GNU Make for data analysis workflows is this JSS 
paper by Peter Baker (http://petebaker.id.au/):

https://doi.org/10.18637/jss.v094.c01

Best wishes,
Z