texi2dvi includes the source file directory in the TeX search path.
This is quite unusual for programs processing -I options (such as C
compilers), and even makeinfo doesn't do that. Furthermore, it's not
possible to remove that directory from the search path.
This patch fixes the problem:
--- texi2dvi 2001/10/13 21:14:22 1.1
+++ texi2dvi 2001/10/13 21:15:21
@@ -353,7 +353,7 @@
# etc. files in ${directory} don't get used in preference to fresher
# files in `.'. Include orig_pwd in case we are in clean mode, where
# we've cd'd to a temp directory.
- common=".$path_sep$orig_pwd$path_sep$filename_dir$path_sep$txincludes$path_sep"
+ common=".$path_sep$orig_pwd$path_sep$txincludes$path_sep"
TEXINPUTS="$common$TEXINPUTS_orig"
INDEXSTYLE="$common$INDEXSTYLE_orig"
@@ -430,7 +430,7 @@
if test -n "$makeinfo"; then
$verbose "Macro-expanding $command_line_filename to $filename_src ..."
sed -f $comment_iftex_sed "$command_line_filename" \
- | $makeinfo --footnote-style=end -I "$filename_dir" $miincludes \
+ | $makeinfo --footnote-style=end $miincludes \
-o /dev/null --macro-expand=- \
| sed -f $uncomment_iftex_sed >"$filename_src"
filename_input=$filename_src
----- Forwarded message from Florian Weimer <rusfw@cert.uni-stuttgart.de> ----- Subject: Bug#115503: texi2dvi: source file directory included in search path Reply-To: Florian Weimer <rusfw@cert.uni-stuttgart.de>, 115503@bugs.debian.org X-Debian-PR-Package: texinfo From: Florian Weimer <rusfw@cert.uni-stuttgart.de> To: Debian Bug Tracking System <submit@bugs.debian.org> X-Reportbug-Version: 1.30 Date: Sat, 13 Oct 2001 23:21:56 +0200 Package: texinfo Version: 4.0b-2 Severity: normal Tags: patch texi2dvi includes the source file directory in the TeX search path. This is quite unusual for programs processing -I options (such as C compilers), and even makeinfo doesn't do that. Furthermore, it's not possible to remove that directory from the search path. This patch fixes the problem:--- texi2dvi 2001/10/13 21:14:22 1.1 +++ texi2dvi 2001/10/13 21:15:21 @@ -353,7 +353,7 @@ # etc. files in ${directory} don't get used in preference to fresher # files in `.'. Include orig_pwd in case we are in clean mode, where # we've cd'd to a temp directory. - common=".$path_sep$orig_pwd$path_sep$filename_dir$path_sep$txincludes$path_sep" + common=".$path_sep$orig_pwd$path_sep$txincludes$path_sep" TEXINPUTS="$common$TEXINPUTS_orig" INDEXSTYLE="$common$INDEXSTYLE_orig" @@ -430,7 +430,7 @@ if test -n "$makeinfo"; then $verbose "Macro-expanding $command_line_filename to $filename_src ..." sed -f $comment_iftex_sed "$command_line_filename" \ - | $makeinfo --footnote-style=end -I "$filename_dir" $miincludes \ + | $makeinfo --footnote-style=end $miincludes \ -o /dev/null --macro-expand=- \ | sed -f $uncomment_iftex_sed >"$filename_src" filename_input=$filename_src----- End forwarded message -----
texinfo.tex, and it might not be possible to TeX them with a different version of TeX macros. (In fact, IIRC the GNU project has in its standards a requirement to include texinfo.tex in the source distribution.) From experience, lots of manuals, especially in packages whose development rate is not too fast, cannot be built with texinfo.tex different from what was used originally. It seems like the amount of incompatible changes in texinfo.tex is quite high, and lots of different versions are floating around, so it's impossible to predict what version will be installed on the target machine. So I think removing the source file directory from the TeX search path in the default mode of operation would be a grave mistake. Perhaps an option to override that would be a good idea. makeinfo doesn't need to consult texinfo.tex, that's why it doesn't add the source directory to the -I list. Btw, can you tell why does this cause you problems?
Eli Zaretskii <eliz@is.elta.co.il> writes: I see, I was not aware of this restriction. I'm afraid, but I have to agree. Especially since texinfo.tex contains no provisions to skip a second inclusion, otherwise you could preload the proper version of texinfo.tex from the command line. Yes, something like "-I-". In addition, the current directory could be moved to the *end* of the search path specified at the command line (but of course in front of the original search path). (Due to the paperwork involved, I won't submit a patch, though. Is this a problem?) I'm using a configuration management system which maintains a stack of baseline directories (one for each branching level), and a directory for the current change (the unit of modification). These directories are layered on top of each other using search path directories to form one virtual directory. Usually, newer versions precede older ones in the search path, but with Texinfo, if the main Texinfo file is in the baseline directory, newer versions of included files in the same directory (but in a different position on the directory stack) are ignored, and the baseline version is used.
On 10/13/01 23:21, Florian Weimer wrote: Hi Florian, Could you check if the issue has been solved in the meantime? Thanks, Hilmar
On 10/13/01 23:21, Florian Weimer wrote:
Hi Florian,
Could you check if the issue has been solved in the meantime?
Thanks,
Hilmar
* Hilmar Preuße: I haven't used Aegis in many, many years, so this no longer impacts me. Looking at the texi2dvi script, the issue is still present, but as Eli explained, it has to behave this way.