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 non-compliant). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Description: OpenPGP digital signature