On 6/21/19 2:47 PM, Stephane Chazelas wrote:
> In http://austingroupbugs.net/bug_view_page.php?bug_id=1222
> I asked that POSIX *allows*, not even mandate an interface
> supported by one sh implementation and documented as such for
> over 25 years (since before the first version of the POSIX.2
> specification) that addresses that: echo -E - "$var"
> That's not such a useless feature. Without it, echo can't be
> used to output arbitrary data, which is exactly what that
> autoconf as_echo is trying to do.

POSIX has already long-documented the fact that echo cannot be used to
output arbitrary data, and recommended the use of printf. autoconf's
as_echo should be viewed as a thin shim around printf these days, rather
than an attempt to portably use echo (the name as_echo hearkens back to
the days when echo was a shell builtin everywhere but printf was not, so
using echo was preferable to forking when it was possible; but while
things have evolved since then, the name stuck).  The fact that bash 5's
behavior breaks as_echo in the presence of certain filenames is
definitely a discouraging regression; but I haven't paid enough
attention to the details of this thread to know if it was broken only in
the initial bash 5 release and since fixed in a followup patch, or if it
is still broken with all of Chet's current official patches applied on top.

> It was rejected (even the "just allowing it") on the ground that
> it would break existing scripts (without providing any evidence;
> no need to look now, I know it does break some).

Part of the reason for that rejection (since I remember being on that
call) was that the only example provided of 'echo -E -' not outputting
the '-' was for zsh in non-POSIX mode - but zsh is already notoriously
and intentionally non-POSIX when not in POSIX mode.  The assumption made
during the teleconference is that zsh in POSIX mode could just as easily
comply with what all other shells do in strict compliance mode of
outputting a literal '-', if zsh still wants to try for POSIX compliance
(and even that fact is less obvious, as we have not had as many comments
from zsh developers as we have had from other shells that are at least
trying to come to common grounds via POSIX).

> That would break scripts that pass "-" as the *first* argument of
> *one* command (echo) and that happen to be interpreted by a shell
> that has implemented that allowed, but not required feature.
> My point was so that POSIX warn people against expecting "echo
> -" to output "-" as it does not in all shells in practice.

Perhaps that point could still be made as a non-normative point in the
application usage section of echo, but if the only shell affected by the
problem is zsh in non-POSIX mode, it felt like a bit much to be added at
the time.

> Instead, now, POSIX want to *mandate* not only allow a feature
> that not a single shell has done, that is not needed at all, and
> that would potentially break all scripts that pass an unquoted
> word expansion containing a backslash in *any* position, in
> *any* argument to *any* command.
> Isn't there some level of double standard there?

You're reading far too much into the outcome of the current discussion.
I'm not yet convinced that POSIX is trying to mandate behavior at odds
with existing shell practice, and the various mailing list threads on
the topic are far from over.   Various proposals may have added words
that can be construed in that manner, but that does not mean that POSIX
has adopted that proposal, nor that it will do without first addressing
the problematic wording.  We intentionally did not reach a final
resolution on the backslash issue on yesterday's call because of the
continued activity on the mailing list.

And the fact that you have demonstrated several time-bombs where
existing shell scripts coupled with historical shell behaviors can
result in non-obvious changes in behavior based on the contents of the
current working directory make this an interesting problem.  But part of
the issue is coming up with acceptable wording that either permits
existing practice (at the risk of rendering common shell script examples
in the wild as tickling unspecified behaviors), or which tightens things
to be less unpredictable (even if it renders existing shells as

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to