GNU bug report logs -
#23239
GNU echo -n argument bug
Previous Next
Reported by: Faissal Bensefia <faissaloo <at> me.com>
Date: Thu, 7 Apr 2016 19:54:02 UTC
Severity: normal
Tags: notabug
Done: Eric Blake <eblake <at> redhat.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 23239 <at> debbugs.gnu.org.
--
23239: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23239
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (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 part 5 (message/rfc822, inline)]
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
This bug report was last modified 9 years and 101 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.