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
Message #18 received at 23239 <at> debbugs.gnu.org (full text, mbox):
[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)]
This bug report was last modified 9 years and 47 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.