Re: /bin/echo -- $var

[Eric Blake]

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

signature.asc
Description: OpenPGP digital signature