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

[Vincent Belaïche]

Le 16/09/2015 12:40, Gavin Smith a écrit :
>> Now here is the funny story, I have made a correction of texi2dvi
>> (attached to this email), and it converts all pathes from MSys to MSW
>> for both input file and TeX envvar, everything seemed ok but compilation
>> of dummy.texi was still failed. So I read the error message a little bit
>> more carefully (one should always read carefully error message to know
>> what the error is, rather than guess it) and I realized that the file
>> that TeX could not find with `{dummy_inc.texi}', not `dummy_inc.texi'
>> (ie erroneously embraced in curly brackets). I could have entered
>> `dummy_inc.texi' instead of `../../../dummy_inc.texi' and it would have
>> also worked, because both pathes are in TEXINPUTS. That was just an
>> error syntax in dummy.texi as I had written
>>
>>    @include{dummy_inc.texi}
>>
>> instead of
>>
>>    @include dummy_inc.texi
>
> So there's no problem then?

The thing is that the code could be simplied:

- replace all ${path_sep} or $path_sep by :
- remove the piece of code with uname | grep -iv 'gygwin|mingw|djgpp',
  that sets path_sep, so that there is no longer any path_sep stuff.

Anyway, as I wrote this code is bogous, it sets path_sep to `;' in the
Linux cases, so this may imply that texi2dvi does not works in some
cases.

>
>
>> But that is not all : indeed MikTeX engines are Msys applications, they
>> understand both path formats, so :
>>
>> - the latest (rev 6609) texi2dvi on the repo works fine on dummy.texi
>>   once the @include syntax error is fixed, and
>> - my latest patch (attached to this email) works also fine
>
> Can you send  the patch instead of the whole file so I can see what you 
> changed?
>
>
>> - my patch is useless for MikTeX 2.9, however I cannot say if this is
>>   the case for other MSW TeX distributions (or earlier MikTeX), can we
>>   rely on this that the engines are Msys application ? And even if that
>>   is the case, what will happen if the tex engines are launched from
>>   another bash implementation (if any ? what djgpp is ?). I don't think
>>   we need to handle cygwin case, I don't know cygwin but what I had
>>   heard is that it is a complete Linux environment with its own TeX
>>   distribution, ie it is more similar to a linux virtual machine,
>>   completely different to what Msys is: a lightweight MSW native *nixy
>>   port with tricks to handle *nixy path format, that is why you can
>>   launch native MSW application from Msys provided that
>
> If we don't know if there's a problem or not, let's not worry about it
> until someone reports a problem on one of those systems.

Simply by reading the code you can see that the path_sep stuff is
bogous, it is better to fix that now.

There is also one less annoying problem in findprog, IFS needs to be
restored in the end for the quite unlikely case when PATH variable is
empty. Please note that under MSW, even though `.' is not in the PATH,
an executable under `.' will be found, so an unlikely scenario would to
have PATH empty provided that all engines tools are in `.'


VBR,
        Vincent

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