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
Description: PGP signature
