On 8/15/19 2:36 AM, Harald Dunkel wrote: > On 8/14/19 3:10 PM, Eric Blake wrote: >> On 8/14/19 7:01 AM, Harald Dunkel wrote: >>> >>> Shouldn't it be just >>> >>> -n >> >> No, because 'echo' is one of the few exceptions to the rule, in that >> POSIX specifically mandates that it NOT recognize -- as an >> end-of-options marker. > > But then the "-n" shouldn't be printed either, should it? "-n" > is a valid command line option for coreutil's /bin/echo (and > the bash builtin, too).
Wrong. Since you called 'echo -- -n', and did not use '-n' first (which is itself a can of worms), the literal output must be '-- -n' (the -- is not ignored as an end-of-option marker, but treated as a literal string). > > This doesn't seem reasonable. Posix says also "Implementations > shall not support any options", i.e. coreutil's echo is violating > Posix, anyway. Partially wrong. In general, '/bin/echo --help' does not ignore --help and goes on to print a lot of text; but that is because in general, most users don't request strict POSIX compliance. If you instead run 'POSIXLY_CORRECT=1 /bin/echo --help', you will output exactly '--help'. That is, when coreutils has been asked to run in POSIX compliance mode, coreutils does NOT violate POSIX. Otherwise, we intentionally violate POSIX in a few spots where it makes sense, but try to limit those spots to as few as possible. Treating -- as an end-of-options marker in non-POSIX mode would break more than it helps, so we do not diverge from POSIX there; but treating --help as an option in non-POSIX mode is essential to your ability to learn whether /bin/echo came from coreutils. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Description: OpenPGP digital signature