Re: texi2dvi unexpected behaivoir

[Gavin Smith]

On 29 April 2016 at 11:48,   wrote:
> I traced the script until the following point:
> texi2dvi line 991 in function 'filter_files':
>   test -n "$xref_files_new" && echo "$xref_files_new" |
> It seems that the script traps at this point and calls the function
> 'cleanup'. I my case, the string "$xref_files_new" has length zero, so I
> would expect that the command fails.
> On the other hand, a second call to texi2pdf works, if not in clean
> mode. Maybe I am using this helper script in a wrong way, but from the
> description I would expect, that the file above should be complied two
> times by texi2dvi with return value 0.
> If however the function is changed to
>
> filter_files ()
> {
>   if [ -n "$xref_files_new" ] ; then
>   echo "$xref_files_new" |
>   # Filter existing files matching the criterion.
>   #
>   while read file; do
> $1 "$file"
>   done |
>   sort |
>   # Some files are opened several times, e.g., listings.sty's *.vrb.
>   uniq
>   fi
> }
>
> (note that just test is replaced by an if-clause), everything works as
> expected for me.

It should have been fixed already. You can get the latest version at
http://ftp.gnu.org/gnu/texinfo/texi2dvi. Discussion here:
http://lists.gnu.org/archive/html/bug-texinfo/2016-02/msg00140.html

texi2dvi unexpected behaivoir

[d . gerbet]

Dear developers,

when compiling tex documents using texi2pdf, texi2pdf returns 1,
although a pdf-file is generated after exactly one compilation cycle.
Within the document the references are missing. A minimal example to
reproduce the behaviour is this file:

foo.tex
---
\documentclass{article}
\begin{document}
\section{foo}\label{foo}
foo \ref{foo}
\end{document}

compiled using
$ texi2pdf -D -V -c foo.tex

I traced the script until the following point:
texi2dvi line 991 in function 'filter_files':
  test -n "$xref_files_new" && echo "$xref_files_new" |
It seems that the script traps at this point and calls the function
'cleanup'. I my case, the string "$xref_files_new" has length zero, so I
would expect that the command fails. 
On the other hand, a second call to texi2pdf works, if not in clean
mode. Maybe I am using this helper script in a wrong way, but from the
description I would expect, that the file above should be complied two
times by texi2dvi with return value 0. 
If however the function is changed to

filter_files ()
{
  if [ -n "$xref_files_new" ] ; then
  echo "$xref_files_new" |
  # Filter existing files matching the criterion.
  #
  while read file; do
$1 "$file"
  done |
  sort |
  # Some files are opened several times, e.g., listings.sty's *.vrb.
  uniq
  fi
}

(note that just test is replaced by an if-clause), everything works as
expected for me. 

My environment:

$ texi2dvi --version
texi2dvi (GNU Texinfo 6.1) 6991

Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ pdflatex --version
pdfTeX 3.14159265-2.6-1.40.16 (TeX Live 2015/Arch Linux)
kpathsea version 6.2.1
Copyright 2015 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
Compiled with libpng 1.6.21; using libpng 1.6.21
Compiled with zlib 1.2.8; using zlib 1.2.8
Compiled with poppler version 0.42.0

$ uname -srvo
Linux 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:19:32 CEST 2016 GNU/Linux

Yours sincerely

Daniel Gerbet

Re: Fwd: REVIEW REQUEST - user manual generation

[Vincent Belaïche]

Le 29/04/2016 00:42, Karl Berry a écrit :
> <>| are not valid in filenames
>
> They are on Unix.  -k


Ooops... After some search on the Web I found this interesting
discussion:

http://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names

In comment #33 somebody says that under *nix the only forbidden
character in a file path is NUL (aka \0), and / cannot be used in
filenames, only as a file separator in paths.

So, this ruins my suggestion to catcode group locally special TeX
characters, as there may be some people (or SW) using <>| in filenames
under *nix for some special file that needs a crazy name to avoid
collision with other names.

However, instead of <>| I could use

\bgroup for group beginning
\egroup for group end
nul for space.

Note, that implicitely I assumed that \ will never be used in a filename,
even under *nix for portability reasons to MSW.

Another method for handling special characters in filenames would be to
prefix all of them by \string (so this would even support filenames
containing \ as part of the filename).

My tex distribution expands all the macros in the filename before using
it, so that would be valid to do simply that for handling ~ and
suchlikes (just some piping the name through
   sed -e 's!\([#~\{}_^$]\)!\\string\1!g'
). However, I don't know whether this behaviour is widely used.

Also, it does not help with space to replace them by `\space ', or by
`\expandtafter\string\space ' to get some litteral space (space with
catcode 11). I have already tried that. The \input command is really
difficult in this that it does not work like other macros as far as
grabbing the argument is concerned.

It seems that LaTeX has redefined \input to support usual {...}
enclosing (under TeX if you use {...}, tex will consider the curly
braces as part of the filename). It would be interesting to test whether
the LaTeX \input allows spaces in filenames, and if yes, how did they
manage to do that.

As a side comment, not related to texi2dvi, it would be good to document
handling of special characters in filenames under LaTeX in latexrefman
manual.

  Vincent.

Re: Fwd: REVIEW REQUEST - user manual generation

[Vincent Belaïche]

Le 29/04/2016 08:55, Vincent Belaïche a écrit :
>
>
> Le 29/04/2016 00:42, Karl Berry a écrit :
>> <>| are not valid in filenames
>>
>> They are on Unix.  -k
>
>

[...]

>
> However, instead of <>| I could use
>
> \bgroup for group beginning
> \egroup for group end
> nul for space.
>

[...]

>
>   Vincent.

Attached is an attempt to do that. Unfortunately using \egroup for group
end does not work, because whether it is a \toks or a \def you need the
the end of the definition terminated by a catcode=2 character.

So, I need only one forbidden character in filenames (in addition to
backslash) to make it.

   Vincent.


Index: texi2dvi

===

--- texi2dvi(revision 7139)

+++ texi2dvi(working copy)

@@ -889,8 +889,10 @@

   # resetting their catcodes to other on the command line and changing
   # texinfo.tex to initialize everything to plain catcodes.  Maybe someday.
 
-  # append the \input command.
-  tex_cmd="$tex_cmd '${escape}input'"
+  # append the \input + input filename.
+  if test $# -gt 0; then
+tex_cmd="$tex_cmd '${escape}input' '$1'"
+  fi
 }
 
 # run_tex - Run TeX as "$tex $in_input", taking care of errors and logs.
@@ -918,14 +920,44 @@

 run rm -f "$_run_tex_file_name"
 run ln -s "$in_input"
   fi
-  tex_cmd="$tex_cmd '$_run_tex_file_name'"
   ;;
 
 *)
-  tex_cmd="$tex_cmd '$in_input'"
+  _run_tex_file_name="$in_input"
   ;;
   esac
 
+
+  # Make input filename relative, in order to alleviate risk of spaces
+  # in name
+  _run_tex_cur_dir=`pwd`
+  case "$_run_tex_file_name" in
+*"$_run_tex_cur_dir"*)
+  # escape special characters
+  _run_tex_cur_dir=`echo "$_run_tex_cur_dir" | $SED -e 
's/\([.$^\]\)/\\\1/g'`
+  _run_tex_file_name=`echo "$_run_tex_file_name" | $SED -e 
"s<^$_run_tex_cur_dir/<./<1"`
+;;
+  esac
+
+  # If there are still spaces remaining the the input file name, we
+  # try double quoting, this is tex implementation and OS dependent,
+  # so that trick may not work always.
+  case "$_run_tex_file_name" in
+*" "*)
+  _run_tex_dq='"'
+  ;;
+*)
+  _run_tex_dq=
+  ;;
+  esac
+  #  >=}  nul=space
+  tex_cmd="$tex_cmd '${escape}bgroup${escape}catcode62=2 ${escape}catcode0=10"
+  # make letter {   }   $  #  ~   space(must be last in this list)
+  for w in  123 125 36 35 126 32; do
+tex_cmd="$tex_cmd ${escape}catcode$w=11";
+  done
+  
tex_cmd="$tex_cmd^^00${escape}toks0${escape}bgroup${escape}input^^00$_run_tex_dq$_run_tex_file_name$_run_tex_dq${escape}relax>${escape}expandafter${escape}egroup${escape}the${escape}toks0^^00'"
+
   verbose "$0: Running $tex_cmd ..."
   if eval "$tex_cmd" >&5; then
 case $out_lang in
@@ -1479,10 +1511,9 @@

 save_batch=$batch
 catcode_special=false
 batch=true
-make_tex_cmd
+make_tex_cmd ./openout.tex
 catcode_special=$save_catcode_special
 batch=$save_batch
-tex_cmd="$tex_cmd ./openout.tex"
 # ./ in case . isn't in path
 verbose "$0: running $tex_cmd ..."
 rm -fr "openout.$2"

Re: Fwd: REVIEW REQUEST - user manual generation

[Vincent Belaïche]

Hello Gavin,

Answers below

Le 28/04/2016 20:35, Gavin Smith a écrit :
> On 28 April 2016 at 09:30, Vincent Belaïche  
> wrote:

[...]

>
> That's what texi2dvi does. The foo~bar.texi file has a line in it
> "\input texinfo" which loads texinfo.tex, and the catcode and active
> definition of ~ are changed again. So the catcode given on the
> command-line isn't lasting.

Yes, the changed catcode for ~ isn't lasting if you compile a Texinfo
file --- which texi2dvi is primary made for --- but it _is_ lasting when
texi2dvi is used to compile a LaTeX file (something I had noticed with
another problem report a few months ago). This is why I was writing that
the method which I proposed (in essence make the catcoding group local,
and then expand it after-group) is superior: it does not affect the
catcodes outside the command line even with LaTeX (well, I have not
tested it yet).

Anyway, this is not the problem on the table now, we are talking
primarilly about another special character: space.

VBR,
Vincent.