bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23239: GNU echo -n argument bug


From: Eric Blake
Subject: bug#23239: GNU echo -n argument bug
Date: Fri, 8 Apr 2016 07:40:39 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]