Re: preconv test failure on Darwin with nixpkgs 25.11 (was: groff 1.24.0.rc4 testing)

"G. Branden Robinson" <[email protected]> Sat, 21 Feb 2026 21:18:12 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260222031812.c6awa6d3yzxbjeyi@illithid>
Hi Alexis,

At 2026-02-21T22:14:50+0100, Alexis (surryhill) wrote:
> On Sat, Feb 21, 2026 at 01:53:01PM +0100, G. Branden Robinson wrote:
> > [please don't email info-groff@gnu with feedback; it's not a big
> > problem, but it makes work for the list moderators]
> 
> Apologies for that and to the list moderators, I seem to have been
> unattentive with regards to the addresses when replying.

It's okay.  I used to go the trouble of setting Mail-Followup-To: in
cases like that, but few MUA vendors seem to have embraced the idea.  :(

I said that mainly so you'd know why your message didn't end up there.

Almost all of what the list moderators see is obvious spam.

> Yes, the nixpkgs output paths are rather long, here's an example
> snippet from groff(7):
> 
>  /nix/store/rjhh3wgj39lr6vvnxyd5ld7y70x9vlj4-groff-1.24.0.rc4/lib/X11/
>  app-defaults
>         Application defaults directory for gxditview(1).

Yeah, that...that's not the easiest thing to typeset.  :)

> > Okay, please run that printf(1) command in your build environment and
> > tell me what you get.  The script `export LC_ALL=C`'s earlier, so you
> > should do similar.
> > 
> > $ LC_CALL=C printf 'Eat at the caf\351.\n'
> 
> /usr/bin/env LC_CALL=C printf 'Eat at the caf\351.\n' | /usr/bin/od -x
> 0000000      6145    2074    7461    7420    6568    6320    6661    2ee9
> 0000020      000a
> 0000021
> 
> To ensure that my MUA doesn't mess with any character encodings from
> the shell I decided to pipe the output to od(1).
> Please find attached print.log which contains the output from
> /usr/bin/script printf.log /usr/bin/env LC_CALL=C printf 'Eat at the caf\351.\n'
> 
> Both of which will hopefully provide you with the necessary information.

Right, I was...not expecting a printf(1) that didn't handle octal
escape sequences in the format string.

And, hmm, it appears that POSIX hasn't standardized that!

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/printf.html

Does _this_ work on your system?

$ LC_ALL=C printf 'Eat the caf%b.\n' '\0351' | od -c
0000000   E   a   t       t   h   e       c   a   f 351   .  \n
0000016

If so, that's apparently what I need to be doing instead.

Note the leading zero in the input sequence of octal digits.

> In my previous message I wrote I was testing on Darwin using nixpkgs
> 25.11 and I should've been more precise. Darwin is the build name
> in nixpkgs for macOS and I'm on macOS 26.2, so that would make
> Apple the libc (or rather libSystem.dylib) vendor.

Right.  I'd have (roughly) predicted that but wanted to be sure.  :)

> Script started on Sat Feb 21 21:59:00 2026
> Command: /usr/bin/env LC_CALL=C printf Eat at the caf\351.\n
> Eat at the café.

While that produces the output I'd expect, you misspelled the
environment variable name.

I would not expect `LC_CALL=C` to have any effect on the process's
locale settings.

The variable name is `LC_ALL`.

This automated test needs to both (1) set up the locale and (2) use a
portable incantation of printf(1).  If we can achieve that on your
system, then I think we have a path to resolving this test failure.

Regards,
Branden
signature.asc (application/pgp-signature, 833 B)