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

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

cheers,
Padraig

Reply via email to