GNU bug report logs - #32703
echo_man_error

Previous Next

Full log

Message #39 received at 32703-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>, 1064240043 <szq1064240043 <at> qq.com>,
 32703-done <at> debbugs.gnu.org
Subject: Re: bug#32703: echo_man_error
Date: Mon, 24 Sep 2018 21:51:30 -0700

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.