[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32703: echo_man_error
From: |
Pádraig Brady |
Subject: |
bug#32703: echo_man_error |
Date: |
Mon, 24 Sep 2018 21:51:30 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 24/09/18 15:15, Eric Blake wrote:
> On 9/23/18 9:48 PM, Pádraig Brady wrote:
>
>> +++ b/NEWS
>> @@ -5,6 +5,12 @@ GNU coreutils NEWS -*-
>> outline -*-
>> ** Bug fixes
>>
>> df no longer corrupts displayed multibyte characters on macOS.
>> + [bug introduced with coreutils-8.18]
>> +
>> +** Changes in behavior
>> +
>> + echo now always processes backslash escapes when the POSIXLY_CORRECT
>> + environment variable is set.
>
> Having re-read the POSIX wording, I'm not quite sure we are still accurate.
>
>> +++ b/src/echo.c
>> @@ -108,8 +108,9 @@ int
>> main (int argc, char **argv)
>> {
>> bool display_return = true;
>> + bool posixly_correct = getenv ("POSIXLY_CORRECT");
>> bool allow_options =
>> - (! getenv ("POSIXLY_CORRECT")
>> + (! posixly_correct
>> || (! DEFAULT_ECHO_TO_XPG && 1 < argc && STREQ (argv[1], "-n")));
>
> This special-cases a literal "-n" as the first argument, while POSIX
> states (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html)
>
> Implementations shall not support any options.
>
> A string to be written to standard output. If the first operand is -n,
> or if any of the operands contain a <backslash> character, the results
> are implementation-defined.
>
> and then with XSI shading states:
>
> On XSI-conformant systems, if the first operand is -n, it shall be
> treated as a string, not an option.
>
> So my initial patch (which you took and improved) still isn't quite right.
I noticed that POSIX wording too,
but erred on the side of consistency:
$ bash -c 'set -o posix; shopt -s xpg_echo; echo -n foo'
-n foo
$ bash -c 'set -o posix; echo -n foo'
foo
$ dash -c 'echo -n foo'
foo
Now we do have compile time control over xpg mode so
should probably restrict the no option processing
to that mode?
In summary the handling of -n specially is weird
and inconsistent with bash, so in a separate patch
I propose we handle all (leading) options also
with POSIXLY_CORRECT to be consistent with bash.
Oh hang on. It's the "xpg_echo" bash setting that enables -e by default :/
We don't have a runtime setting for that at present.
$ bash -c 'set -o posix; echo -ne a\\nb\\n'
a
b
bash -c 'set -o posix; echo -E a\\nb'
a\nb
$ bash -c 'set -o posix; shopt -s xpg_echo; echo a\\nb'
a
b
$ bash -c 'set -o posix; echo a\\nb'
a\nb
$ bash -c 'set -o posix; echo -e a\\nb'
a
b
So there is no way to be consistent with bash and dash I think.
Let's have bash and coreutils consistent at least.
The only question is whether POSIXLY_CORRECT in coreutils
is equiv to `shopt -s xpg_echo` in bash or not.
Assuming it is, then we'll need to echo -n when set as you say.
Le sigh. What a mess
cheers,
Pádraig
- bug#32703: echo_man_error, 1064240043, 2018/09/11
- bug#32703: echo_man_error, Eric Blake, 2018/09/11
- bug#32703: echo_man_error, Eric Blake, 2018/09/11
- bug#32703: echo_man_error, Pádraig Brady, 2018/09/23
- bug#32703: echo_man_error, Eric Blake, 2018/09/24
- bug#32703: echo_man_error, Bernhard Voelker, 2018/09/24
- bug#32703: echo_man_error, Pádraig Brady, 2018/09/25
- bug#32703: echo_man_error, Eric Blake, 2018/09/24
- bug#32703: echo_man_error,
Pádraig Brady <=