bug#23239: GNU echo -n argument bug

[Ruediger Meier]

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".

> 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/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

And probably it's also "over-strict" to forbid GNU coreutils' uniq 
options --help and --version ... which makes it even incompatible to 
GNU bash.

> '-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.