GNU bug report logs - #32703
echo_man_error

Previous Next

Package: coreutils;

Reported by: "1064240043" <szq1064240043 <at> qq.com>

Date: Tue, 11 Sep 2018 15:19:02 UTC

Severity: normal

Tags: moreinfo

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


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

From: Eric Blake <eblake <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>,
 1064240043 <szq1064240043 <at> qq.com>, 32703-done <at> debbugs.gnu.org
Subject: Re: bug#32703: echo_man_error
Date: Mon, 24 Sep 2018 17:15:56 -0500
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.

> +
> +# With POSIXLY_CORRECT:
> +#   only -n as the first (separate) option enables option processing

Rather, not even -n should get special treatment as an option.

> +#   -E is ignored
> +#   escapes are processed by default
> +POSIXLY_CORRECT=1 $prog -n -E 'foo\n' > out || fail=1

So I would argue that this should output $'-n -E foo\n'.

> +POSIXLY_CORRECT=1 $prog -nE 'foo' >> out || fail=1
> +POSIXLY_CORRECT=1 $prog -E -n 'foo' >> out || fail=1
> +POSIXLY_CORRECT=1 $prog --version >> out || fail=1
> +cat <<\EOF > exp
> +foo
> +-nE foo
> +-E -n foo
> +--version
> +EOF
> +compare exp out || fail=1
-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org




This bug report was last modified 6 years and 266 days ago.

Previous Next


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