Pádraig Brady <[email protected]> writes:
> On 18/02/2026 01:30, Collin Funk wrote:
>> Pádraig Brady <[email protected]> writes:
>>
>>> * tests/csplit/csplit-io-err.sh: Adjust determination of ENOSPC.
>>> * tests/csplit/split-io-err.sh: Likewise.
>>> * tests/fold/fold-zero-width.sh: Verify full ENOSPC message.
>>> * tests/tac/tac-continue.sh: Likewise.
>>> * tests/misc/io-errors.sh: Likewise.
>>> * tests/misc/write-errors.sh: Likewise.
>>> ---
>>> tests/csplit/csplit-io-err.sh | 7 ++-----
>>> tests/fold/fold-zero-width.sh | 2 +-
>>> tests/misc/io-errors.sh | 3 ++-
>>> tests/misc/write-errors.sh | 2 +-
>>> tests/split/split-io-err.sh | 7 ++-----
>>> tests/tac/tac-continue.sh | 3 ++-
>>> 6 files changed, 10 insertions(+), 14 deletions(-)
>> The fold-zero-width.sh one fails because we are in the french
>> locale:
>> + grep 'No space left on device' err
>> + fail=1
>> + cat err
>> fold: write error: Aucun espace disponible sur le périphérique
>> + echo 'fold didn'\''t diagnose ENOSPC'
>> fold didn't diagnose ENOSPC
>> The other changes look good from my quick look.
>> Maybe we can optionally set the locale in getlimits_ for test cases
>> like
>> this?
>
> Oh interesting.
> The test passed for me.
> So why was english used in my (Fedora 43) case?
> Because the locale messages failed to load due to the constrained mem.
>
> openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=233242544, ...}) = 0
> mmap(NULL, 233242544, PROT_READ, MAP_PRIVATE, 3, 0) = -1 ENOMEM (Cannot
> allocate memory)
>
> I verified by making this adjustment to the test which caused it to fail for
> me too:
>
> - "(ulimit -v $(($vm+12000)) && fold 2>err >/dev/full)"+ "(ulimit -v
> $(($vm+232000)) && fold 2>err >/dev/full)"
>
> So Fedora 43 needs to map 230M to load translations!
> That is with this installed:
>
> $ rpm -qf /usr/lib/locale/locale-archive
> glibc-all-langpacks-2.42-4.fc43.x86_64
Maybe there were some changes in the newer version I have:
$ rpm -qf /usr/lib/locale/locale-archive
glibc-all-langpacks-2.42-9.fc43.x86_64
>
> So how to address this.
> It's best to keep messages in C I think
> given the mem constrained binary may fall back to C messages.
>
> Note setting LC_CTYPE separately to LC_MESSAGES can be problematic
> on OS X 10.5.8 which is unfortunate: https://bugs.gnu.org/26044
> But testing macOS 26.2 doesn't seem to have the same limitation.
> In any case we skip the test where these constraints don't hold.
>
> So I think I'll merge in this adjustment:
>
> -LC_ALL=$LOCALE_FR_UTF8
> -export LC_ALL
> +unset LC_ALL
> +LC_CTYPE=$LOCALE_FR_UTF8
> +export LC_CTYPE
I have run it a few times now and it works fine.
MacOS 10.5.8 is quite old, so I would not be surprised if there are
larger issues to solve there. I wouldn't worry too much about it here.
Thanks,
Collin
