* On 04.07.2014 05:55 pm, Mojca Miklavec wrote: > [...] > > My other suggestions to fix the problem would be the following: > > a) either allow compiling texinfo with ./configure > --with-sed=/path/to/somesed, so that whenever texinfo is called, it > would use that variable to cal "the right sed"; or use some other > trick somewhere to achieve the same
That sounds great. autotools could substitute the correct sed binary easily, if
scripts/binaries are generated from file.in (like, texi2dvi.in.)
> b) set LC_CTYPE=C (I forgot the exact details, but the same is done in
> LuaTeX to avoid problems in different areas); I believe that there is
> no need to actually detect the encoding, I suspect that anything other
> than UTF-8 (that is: C or some ISO encoding accepting any 8-bit char)
> would be fine
That will fail for UTF-8 encoded files, I guess. Hence, I asked for automatic
input charset detection. As that's not possible, I opt for a.)
> I totally agree that "there is no way to detect charsets reliably",
> but I hope that "C" would work. Not using Apple's sed is a bit
> difficult to set up. In configure scripts it is usually easy to do
> something like "export SED=gnused" or "export MAKE=gmake" or things
> like that. But "sed" is hardcoded in texinfo and it's a bit difficult
> to change it.
>
> So I would paraphrase the question: would it be possible to select
> which SED is used in advance or would it be possible to set some
> environmental variables that would make any given "sed" happy?
Replacing calls to sed by a ${SED} variable which can be set to arbitrary values
from the environment sounds fine, too (with defaulting on the general "sed".)
That would, however, still require to set a SED env variable for all ports
breaking with bsdsed. Maintainers would also need to know about this...
> If that doesn't get fixed, MacPorts will have to patch texinfo with
> ugly workarounds that will make extra burden on both the MacPorts
> maintainers (having to keep patching new versions of texinfo, prone to
> errors as well) as well as texinfo developers (by getting weird bug
> reports from users that wouldn't be your problem at all and that would
> be hard to debug).
smime.p7s
Description: S/MIME Cryptographic Signature
