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

[Gavin Smith]

On 3 September 2015 at 22:02, Vincent Belaïche
<address@hidden> wrote:
> 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.

It stops the output files (log or fls) being grep'd multiple times.
Although I do see that it could be harder to follow what's happening.
I did it the way you suggested, and it worked okay.

>
>    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.

Yes, you're right there.

> 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.

OK.

> 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.

Maybe the recorder file is separate from the other files in a way and
there's no problem with it having the same name as a file opened with
\openout or \openin?

>From the point of view of the operating system, there's no problem,
because these are two different files, in different directories. It
depends then on the point of view of the TeX program.

>    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...

I'm just learning about the TEXINPUTS environment variable for web2c
and kpathsea, but if we can't control the TeX search path, then there
would seem to be no hope.

I've attached an updated patch. I'm going to get this committed to the
repository, as a base for further work.

texi2dvi
Description: Binary data

texi2dvi.diff4
Description: Binary data