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

Previous Next

Package: coreutils;

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):

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)]

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.