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.
