Re: [bug #43122] texi2dvi does not compile enough times to get toc

[Vincent Belaïche]

Hello Gavin,

I had a look to your second patch, and I have some comments

1) on the way that you have factorized code between functions
   generated_files_get_from_fls and generated_files_get_from_log, what
   you did is call one of this functions inside generated_files_set and
   place the result in a variable generated_files, and then echo this
   variable content as the first stage of the pipe inside
   generated_files_get. It seems over-complex compared to the method
   which I have used in my second patch : just call one of these two
   functions by using a function pointer $generated_files_raw_get as the
   first stage of the pipe.

   Also, I don't understand why you need to bracketize

    (
      echo "$generated_files"
    )

   the `( ... )' brackets make `echo "$generated_files"' to run in a
   subshell, loading and unloading the subshell uselessly costs extra
   processing power. Well, in fact, as each command in a pipe is
   executed in its own subshell (for bash, I presume it is the same for
   sh) I don't know what sh really does : do the (...) create a subshell
   or the subshell ? Anyway you don't need explicit subshelling here,
   just like in my solution there aren't any rounded brackets needed
   either.

   In the original code, the purpose of the `(...)' was to append the
   "$1.log" at the end of the raw list of files extracted from $1.log. A
   `{...}' construct would have done the deal without subshelling, but I
   don't know whether sh supports `{...}' construct.

2) in make_openout_test, please remember if you later uncomment the
         # > /dev/null 2&>1

   that it should be `2>&1' instead of `&2>1'. See my previous email.

3) please remember to have one space before the function `()' --- please
   see my previous email.

4) I don't think that the .fls to .flz renaming can work properly. The
   problem is that whatever renaming you use, you will still have at
   some point tex writing the .fls file as a recorder file, at the same
   time as reading it as an \input file. My suggestion would be to carry
   out some fl->_0 renaming in the texinfo.tex rather. See my previous
   email.

   I am not even sure that MikTeX consider at all the TEXINPUTS env
   variable. Anyway, even if MikTeX would consider this variable that
   would not work if you need it, because texi2dvi is running under
   MSYS, so the path are set à la MSYS,
   e.g. /c/Programmes/installation/texinfo-install/trunk/util/dummy.t2d/pdf/bak,
   while MikTeX expect MSWindows path, with `c:' instead of `/c'. In
   general, the use of absolute paths instead of relative paths makes
   things more difficult when you are mixing non MSYS application in an
   MSYS environment.

   I made a test of your patch with the dummy.texi attached, and it
   worked fine for the fls/fl/flz stuff when starting from scratch. But,
   I think that this is just a lucky strike, and I will strive to make
   it fail...

VBR,
        Vincent.


Le 01/09/2015 19:40, Gavin Smith a écrit :
> On 30 August 2015 at 22:56, Karl Berry <address@hidden> wrote:
>>     Possible problem: a *.fls file meets the *.??s glob pattern for sorted
>>     index files. Probably not a problem.
>>
>> I have used, and still use, an "fl" index in actual documents.  So it
>> seems like it is in fact a conflict, unfortunately.  I doubt there is
>> any portable way to specify the recorder file name.  Sigh.  -k
>>
>
> I tried with a fl index and indeed it broke.
>
> My first idea was to rename the recorder file from *.fls, e.g. to
> *.flz. This didn't work though, I think because the final run of TeX
> has *.fls open for writing, stopping it being opened for reading.
>
> I realised that there are two sets of auxiliary files, the old and the
> new, so we could read from the old while writing to the new (i.e.
> overwriting the *.fls file).
>
> I've attached what I have so far. I make the saved files take priority
> by taking . away from the beginning of the TEXINPUTS environment
> variable. I reordered the execution so we could rename the *.fls log
> file before it's overwritten by texindex.
>
> Also the change of the catcode of ~ doesn't affect the test that's
> been added, so I leave that alone.
>
> I was hoping to stop texinfo.tex being read from the current
> directory, but that seems not to work. (Even "tex info.texi" uses
> texinfo.tex in the current directory instead of that which has been
> installed.) Also the -I flags don't override texinfo.tex in the
> current directory. This has caused me problems before. But on further
> thought, it does make sense for "\input texinfo" in a TeX (Texinfo)
> file to look for a "texinfo" file in the same directory.
>
> I'm not too confident what I have here is right - there are quite a
> few combinations, like pwd = directory containing file or not, whether
> --tidy is used, whether index files already existed, whether index
> files already existed in a *.t2d subdirectory after a --tidy run.
> There are several ways to fail, for example no index at all, and
> harder to spot, out-of-date indices, or texi2dvi running TeX too many
> times. (I make that 48 tests required, which I'm sure I haven't done.)
> Everyone please test with your favourite Texinfo (and/or LaTeX)
> documents in creative ways and report what breaks.



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com

dummy.texi
Description: application/texinfo