On 09/04/2015 04:23 PM, Robert "Finny" Merrill wrote:
> On Fri, Sep 4, 2015 at 3:05 PM, Eric Blake <eblake@redhat.com> wrote:
>> On 09/04/2015 01:30 PM, Robert "Finny" Merrill wrote:
>> It's not "shall not be recognized [ever]", but "shall not be recognized
>> in the manner [common to most utilities].  The very next phrase says
>> that it "shall be recognized as a string operand".
>>
>> Or put another way, as a special case for the 'echo' utility, '--' shall
>> be treated the same as any other argument, and always be output
>> literally, rather than being recognized as the special elided
>> end-of-options marker, because 'echo' does not understand options (at
>> least when POSIX rules are in effect).
> 
> So then, when POSIX rules /aren't/ in effect, why not have -- work as
> it usually does, since we're already breaking those rules by accepting
> the --help option?

Because then coreutils' echo would needlessly differ from bash's echo,
and because who knows what existing scripts have come to rely on the
behavior and might break as a result.  The use of
POSIXLY_CORRECT=anything to change behavior is not something done
lightly, and we are loathe to make it control more than a bare minimum
of behavior changes.

[As it is, bash has a bug:
$ (shopt -s xpg_echo; echo -e)

should output '-e', but currently outputs nothing.  Also, bash does not
quite treat POSIXLY_CORRECT=1 (also spelled 'set -o posix') as the
override to turn on full POSIX compliance, as it leaves xpg_echo as a
separate knob; ideally, turning on posix compliance in bash should turn
on xpg_echo - but enough people are used to the old behavior that it was
decided to keep the knobs separate]

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org