GNU bug report logs - #23239
GNU echo -n argument bug

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23239 in the body.
You can then email your comments to 23239 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Faissal Bensefia <faissaloo <at> me.com>
To: bug-coreutils <at> gnu.org
Subject: GNU echo -n argument bug
Date: Thu, 07 Apr 2016 20:27:27 +0100

Hey,
I stumbled across a bug in GNU coreutils' echo, if I use echo with an
option like -nn or -nnnnnnn it should be treated as something echoable
and echo "-nnnnnnn\n" but it doesn't, instead it takes it as an -n
argument and just doesn't echo with a newline. If I were to however put
a character that is not an 'n' in the long string of ns it does echo it
as it should.

Thank you for your time,
~Faissal Bensefia

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

From: Eric Blake <eblake <at> redhat.com>
To: Faissal Bensefia <faissaloo <at> me.com>, 23239-done <at> debbugs.gnu.org,
 GNU bug control <control <at> debbugs.gnu.org>
Subject: Re: bug#23239: GNU echo -n argument bug
Date: Thu, 7 Apr 2016 16:30:33 -0600

[Message part 1 (text/plain, inline)]

tag 23239 notabug
thanks

On 04/07/2016 01:27 PM, Faissal Bensefia wrote:
> Hey,
> I stumbled across a bug in GNU coreutils' echo, if I use echo with an
> option like -nn or -nnnnnnn it should be treated as something echoable
> and echo "-nnnnnnn\n" but it doesn't, instead it takes it as an -n
> argument and just doesn't echo with a newline. If I were to however put
> a character that is not an 'n' in the long string of ns it does echo it
> as it should.

POSIX says it is not portable to use 'echo' with ANY string that starts
with '-':
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

and that you should favor printf instead.

Furthermore, it states that the magic -n option (which has
implementation-defined behavior) MUST be spelled exactly '-n' (and not
'-nnnn'), to trigger the XSI behavior.  Any other spelling has undefined
results.

So in coreutils, we've taken the following approach: by default, parse
the options the same way getopt() always does; ANY sequence of options
is treated as that option.  In your case, you get the same as if you had
specified multiple '-n' options:

$ /bin/echo -nnn hi | od -tx1 -An
 68 69

But if you don't like the default, then ask for POSIX compliance:

$ POSIXLY_CORRECT=1 /bin/echo -nnn hi | od -tx1 -An
 2d 6e 6e 6e 20 68 69 0a

where we explicitly honor EXACTLY '-n'.

As such, I don't see any problem with our current behavior, and am
closing out this bug report. But feel free to add further comments.

Also, there's a big long thread recently in the Austin Group:
http://thread.gmane.org/gmane.comp.standards.posix.austin.general/12097

which concludes that POSIX is probably over-strict (by requiring exactly
'-n', it forbids the relatively common '-e', '-E' and even '-ne' or
'-en' options), but that changing the wording is an uphill battle:

> echo "---- cut here ----" is perfectly safe and the standard
> should not be changed to imply that it is not safe. For this
> reason, I believe there is zero chance that Robert's wording
> will achieve consensus. To be accepted, the new wording will
> need to add only a narrow set of cases to the implementation-
> defined behaviour.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #15 received at 23239 <at> debbugs.gnu.org (full text, mbox):

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: 23239 <at> debbugs.gnu.org,
 eblake <at> redhat.com,
 faissaloo <at> me.com
Subject: Re: bug#23239: GNU echo -n argument bug
Date: Fri, 8 Apr 2016 08:15:00 +0200

On Friday 08 April 2016, Eric Blake wrote:
> tag 23239 notabug
> thanks
>
> On 04/07/2016 01:27 PM, Faissal Bensefia wrote:
> > Hey,
> > I stumbled across a bug in GNU coreutils' echo, if I use echo with
> > an option like -nn or -nnnnnnn it should be treated as something
> > echoable and echo "-nnnnnnn\n" but it doesn't, instead it takes it
> > as an -n argument and just doesn't echo with a newline. If I were
> > to however put a character that is not an 'n' in the long string of
> > ns it does echo it as it should.
>
> POSIX says it is not portable to use 'echo' with ANY string that
> starts with '-':
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

Could you please point me to the exact sentence where they mention "ANY 
string that starts with "-"? I see only notes about "-n".

> and that you should favor printf instead.
>
> Furthermore, it states that the magic -n option (which has
> implementation-defined behavior) MUST be spelled exactly '-n' (and
> not '-nnnn'), to trigger the XSI behavior.  Any other spelling has
> undefined results.
>
> So in coreutils, we've taken the following approach: by default,
> parse the options the same way getopt() always does; ANY sequence of
> options is treated as that option.  In your case, you get the same as
> if you had specified multiple '-n' options:
>
> $ /bin/echo -nnn hi | od -tx1 -An
>  68 69
>
> But if you don't like the default, then ask for POSIX compliance:
>
> $ POSIXLY_CORRECT=1 /bin/echo -nnn hi | od -tx1 -An
>  2d 6e 6e 6e 20 68 69 0a
>
> where we explicitly honor EXACTLY '-n'.
>
> As such, I don't see any problem with our current behavior, and am
> closing out this bug report. But feel free to add further comments.
>
> Also, there's a big long thread recently in the Austin Group:
> http://thread.gmane.org/gmane.comp.standards.posix.austin.general/120
>97
>
> which concludes that POSIX is probably over-strict (by requiring
> exactly '-n', it forbids the relatively common '-e', '-E' and even
> '-ne' or

And probably it's also "over-strict" to forbid GNU coreutils' uniq 
options --help and --version ... which makes it even incompatible to 
GNU bash.

> '-en' options), but that changing the wording is an uphill battle:
> > echo "---- cut here ----" is perfectly safe and the standard
> > should not be changed to imply that it is not safe. For this
> > reason, I believe there is zero chance that Robert's wording
> > will achieve consensus. To be accepted, the new wording will
> > need to add only a narrow set of cases to the implementation-
> > defined behaviour.

Message #18 received at 23239 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Ruediger Meier <sweet_f_a <at> gmx.de>, 23239 <at> debbugs.gnu.org, faissaloo <at> me.com
Subject: Re: bug#23239: GNU echo -n argument bug
Date: Fri, 8 Apr 2016 07:40:39 -0600

[Message part 1 (text/plain, inline)]

On 04/08/2016 12:15 AM, Ruediger Meier wrote:
> On Friday 08 April 2016, Eric Blake wrote:
>> tag 23239 notabug
>> thanks
>>
>> On 04/07/2016 01:27 PM, Faissal Bensefia wrote:
>>> Hey,
>>> I stumbled across a bug in GNU coreutils' echo, if I use echo with
>>> an option like -nn or -nnnnnnn it should be treated as something
>>> echoable and echo "-nnnnnnn\n" but it doesn't, instead it takes it
>>> as an -n argument and just doesn't echo with a newline. If I were
>>> to however put a character that is not an 'n' in the long string of
>>> ns it does echo it as it should.
>>
>> POSIX says it is not portable to use 'echo' with ANY string that
>> starts with '-':
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
> 
> Could you please point me to the exact sentence where they mention "ANY 
> string that starts with "-"? I see only notes about "-n".

"
    The echo utility shall not recognize the "--" argument in the manner
specified by Guideline 10 of XBD Utility Syntax Guidelines; "--" shall
be recognized as a string operand.

    Implementations shall not support any options.

string
    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.
"

Okay, so it doesn't forbid ANY string starting with -, only that such
strings are not options.  But coreutils' behavior definitely falls under
the POSIX discussion I mentioned earlier:

>>
>> Also, there's a big long thread recently in the Austin Group:
>> http://thread.gmane.org/gmane.comp.standards.posix.austin.general/120
>> 97
>>
>> which concludes that POSIX is probably over-strict (by requiring
>> exactly '-n', it forbids the relatively common '-e', '-E' and even
>> '-ne' or

There's certainly a possibility that someone may propose wording to make
POSIX cater to existing implementations, and their various quirks.

> 
> And probably it's also "over-strict" to forbid GNU coreutils' uniq 
> options --help and --version ... which makes it even incompatible to 
> GNU bash.

Coreutils complies with POSIX here:

$ /bin/echo --help | head -n1
Usage: /bin/echo [SHORT-OPTION]... [STRING]...
$ POSIXLY_CORRECT=1 /bin/echo --help
--help

When you ask for POSIX compliance, coreutils treats --help as a literal
string, exactly as required in the current wording.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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