texinfo: texi2dvi incompatible with bsdsed

[Ionic (Mihai Moldovan)]

texinfo's texi2dvi command is incompatible with bsdsed in the case of texinfo files requiring recode.

An incarnation of that can be seen in #38744.

A far as I can see, we have to options: ping upstream on this issue and hope for them to resolve the bug, or rewrite texi2dvi (and possibly other tools?!) to use "gsed" instead of just "sed".

[cooljeanius (Eric Gallager)]

Cc Me!

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

Doesn't texi2dvi belong to texinfo (non-maintained port) rather than TeX Live?

Is anyone willing to come up with a minimal example and send a bug report?

REPORTING BUGS
       Report bugs to bug-texinfo at gnu.org, general questions and discussion to help-texinfo at gnu.org.
       GNU Texinfo home page: <http://www.gnu.org/software/texinfo/>
       General help using GNU software: <http://www.gnu.org/gethelp/>

[Ionic (Mihai Moldovan)]

Mea culpa. Indeed, it does. Would you please be so kind to remove dports and change the description + affected port to texinfo?

I blindly relied on the maxima port to get its dependencies right (obviously, it's depending on texlive for +printable_docs) and didn't even bother to double-check, whether texi2dvi is actually included in texlive.

I could try coming up with a minimal example... at least I kind-of-know what is causing this bug.

[Ionic (Mihai Moldovan)]

Minimal testcase showcasing the bug when being converted with texi2dvi --pdf --batch foo.texi.

[Ionic (Mihai Moldovan)]

I'm just not sure what to do with that.

Sure, texi2dvi fails with bsdsed and it doesn't with gnused. But does this mean, that it is a texinfo bug?

The baseline is bsdsed as shipped by Apple failing when being run on any input containing non-ASCII characters.

To make matters even more complicated: it fails only when LC_CTYPE is set to any UTF-8 locale. Running LC_CTYPE=C LANG=C texi2dvi --pdf --batch foo.texi works fine.

So... I guess texi2dvi needs some more code to detect the input file's charset and and change the LC_CTYPE and LANG environment variables accordingly to some locale supporting the detected charset... but does that make sense?

[Ionic (Mihai Moldovan)]

Upstream is not interested.

We'll have to set LC_ALL in our build environment based on the input file's encoding (and hope they don't switch between UTF-8 and other encodings for different input files.)

You may set this ticket's status to invalid.

[mojca (Mojca Miklavec)]

Do you have any pointers to the relevant conversation?

I would prefer to wait a tiny bit before closing this as invalid. It's not tooooo difficult to fix even if upstream disagrees to make any changes. In principle we could even "hardcode-replace" the sed with gsed to make the tool work in the first place.

[Ionic (Mihai Moldovan)]

Pointer: ​Bug report answer

We could change the scripts to call gsed... but that would require to take a look at all binaries/scripts. Shall I rather do that? It would make texinfo more difficult to maintain, as one must check for new occurrences of sed in new files for instance.

[mojca (Mojca Miklavec)]

patch to the latest unreleased version of texi2dvi to avoid problems with sed

[mojca (Mojca Miklavec)]

Committed in r121939. Once we confirm that it works properly the ticket may be closed.

[Ionic (Mihai Moldovan)]

Works for me.