Subject: bug#23239: closed (Re: bug#23239: GNU echo -n argument bug)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 07 Apr 2016 22:31:02 +0000

Your bug report

#23239: GNU echo -n argument bug

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
23239: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23239
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#23239: GNU echo -n argument bug
From: Eric Blake <[email-masked]>
To: Faissal Bensefia <[email-masked]>, [email-masked], GNU bug control <[email-masked]>
Date: Thu, 7 Apr 2016 16:30:33 -0600
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: GNU echo -n argument bug
From: Faissal Bensefia <[email-masked]>
To: [email-masked]
Date: Thu, 07 Apr 2016 20:27:27 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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