Re: dvi, pdf rules: incorrect invocation of texi2dvi, texi2pdf

[Bruno Haible]

[Adding bug-texinfo. For the context, this thread started at
 <http://lists.gnu.org/archive/html/bug-automake/2009-04/msg00024.html>]

> > How to reproduce:
> > 
> > - Install texinfo 4.13 in your PATH.
> > - Unpack GNU hello 2.4.
> > $ ./configure
> > - Get the newest texinfo.tex:
> > $ gnulib-tool --copy-file build-aux/texinfo.tex
> > $ cd doc
> > - edit hello.texi, inserting an @arrow{} in the first paragraph, after
> >   "friendly greeting". The macro @arrow is supported since texinfo 4.12.
> 
> Weird.  TEXINPUTS works for me.  I have
> ii  texlive-base-bin   2007.dfsg.1-2      TeX Live: Essential binaries
> ii  texinfo            4.11.dfsg.1-4      Documentation system for on-line 
> information and pri
> texi2dvi (GNU Texinfo 4.13) 1.138
> 
> 
> and exactly the above sequence gets me to a working DVI; see below.
> Even the TeX versions are identical to yours on this Ubuntu system.

Thanks for this feedback. A quick look at the uses of TEXINPUTS in both
openSUSE and Ubuntu revealed that the path hacking takes place in
/usr/share/texmf/web2c/texmf.cnf in both cases,

A closer look at what happens on my system:

"make dvi" calls texi2dvi like this:

  env 
TEXINPUTS=../build-aux::/home/bruno/.TeX:/usr/share/doc/.TeX:/usr/doc/.TeX \
  /bin/sh /arch/x86-linux/gnu/bin/texi2dvi hello.texi

This spawns a child process like this:

  env 
TEXINPUTS=.:/home/bruno/data/tmp/hello-2.4/doc:/home/bruno/data/tmp/hello-2.4/doc/.::/home/bruno/data/tmp/hello-2.4/build-aux::/home/bruno/.TeX:/usr/share/doc/.TeX:/usr/doc/.TeX
 \
  etex --file-line-error ./hello.texi

Here you see that there is an empty path element ('::') before the build-aux
directory. And indeed, when I shrink it to ':' (no empty path element before
build-aux), the command passes.

So what's happening is that
  1) texi2dvi inserts an empty path element before the original value of
     TEXINPUTS.
  2) 'etex' interprets an empty path element as "look in the default search
     path of the TeX distribution".

That's a bug in texi2dvi, IMO. Indeed, the attached patch fixes the problem.
For texinfo, this is only half of the required work. The other half should be
to add a unit test against this bug.

For automake, the workaround is simple: Add a -I option always, for example
'-I .'. The texi2dvi bug occurs only if no -I options are passed.


2009-04-07  Bruno Haible  <address@hidden>

        Fix the TEXINPUTS replacement computed by texi2dvi. When no -I option
        is specified, it added an empty path element in front of the original
        value of TEXINPUTS. This is wrong; the empty path element should only
        come after the explicitly specified TEXINPUTS.
        * util/texi2dvi (compile): If there were no -I options, don't add an
        empty path element to $common.

*** util/texi2dvi-4.13  2009-04-07 11:14:34.000000000 +0200
--- util/texi2dvi       2009-04-08 00:57:23.000000000 +0200
***************
*** 1409,1415 ****
    # files in `.'.  Include orig_pwd in case we are in clean build mode, where
    # we've cd'd to a temp directory.
    txincludes=`list_infix includes $path_sep`
!   common="$orig_pwd$path_sep$in_dir$path_sep$txincludes$path_sep"
    for var in $tex_envvars; do
      eval val="\$common\$${var}_orig"
      # Convert relative paths to absolute paths, so we can run in another
--- 1409,1419 ----
    # files in `.'.  Include orig_pwd in case we are in clean build mode, where
    # we've cd'd to a temp directory.
    txincludes=`list_infix includes $path_sep`
!   if test -n "$txincludes"; then
!     common="$orig_pwd$path_sep$in_dir$path_sep$txincludes$path_sep"
!   else
!     common="$orig_pwd$path_sep$in_dir$path_sep"
!   fi
    for var in $tex_envvars; do
      eval val="\$common\$${var}_orig"
      # Convert relative paths to absolute paths, so we can run in another