On 3/21/24 14:45, Bernhard Voelker wrote:
On 3/21/24 00:56, Paul Eggert wrote:
On 3/20/24 15:53, Bernhard Voelker wrote:
Yes, that's the expected behavior for this contrived case. Just as one
would get odd behavior if one did the same thing without --exchange.
There's another which is not
Hi,
I just discovered a printf bug for at least the nb_NO and nn_NO locales
when printing numbers with thousands separator. To reproduce:
#!/bin/bash
for l in de_DE en_US nb_NO ; do
echo "LC_NUMERIC=$l.UTF-8"
for n in 1 100 1000 1 10 100 1000 ; do
On Mär 22 2024, Pádraig Brady wrote:
> Though I see bash 5.2.26 has issue with it :/
>
> $ test \( -a \) -a \( -a \)
> bash: test: `)' expected
>
> bash doesn't like the -a in particular, and is ok with other strings:
That's because in bash -a is ambiguous:
-a FILETrue if file
On 22/03/2024 11:20, Vincent Lefevre wrote:
With GNU Coreutils 9.4, both "test -a -a -a" and "test -o -o -o" fail:
$ export POSIXLY_CORRECT=1
$ /usr/bin/test -a -a -a ; echo $?
/usr/bin/test: ‘-a’: unary operator expected
2
$ /usr/bin/test -o -o -o ; echo $?
/usr/bin/test: ‘-o’: unary operator
With GNU Coreutils 9.4, both "test -a -a -a" and "test -o -o -o" fail:
$ export POSIXLY_CORRECT=1
$ /usr/bin/test -a -a -a ; echo $?
/usr/bin/test: ‘-a’: unary operator expected
2
$ /usr/bin/test -o -o -o ; echo $?
/usr/bin/test: ‘-o’: unary operator expected
2
According to POSIX, they should
On Wed, Mar 20, 2024 at 11:53:05PM +0100, Bernhard Voelker wrote:
> On userland OTOH, we have broader choice.
> Karel did his choice in util-linux for exch(1), and coreutils could expose
> the same functionality.
>
> For other feature requests, we were much more reluctant in coreutils ... for
>
