2019-06-21 15:18:49 -0500, Eric Blake:
> 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.

Chet has clarified that it was intentional and to match Geoff's
interpretation of the standard. Chet has just mentioned he's
added a new posixglob option (on by default) to the devel branch
which when disabled reverts to the old behaviour.

To quote two striking examples that have already been given,
that interpretation of the standard would mean that:

grep $pattern file

Which in all shells is documented to search for lines that
contain a dot in "file" would now be required to instead search
for lines that contain at least one character in "file", as \ is
now a glob quoting operator, and \. happens to match the .
directory entry (on those systems where . is included in the
result of readdir() at least and with shells that don't skip .
and .. in glob expansions).


touch %sn
cmd='printf %s\n'
$cmd test

which in all shells is documented to output test<newline> would
now be required to output testn (without newline).

That's what bash5 now implements.

> > 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).

Yes, you may have noticed that I didn't argue with that
decision, I'm just bringing it up as a striking and relevant
example to compare with Geoff's proposed change (or
interpretation of the standard).

I did forward the decision to the zsh developers back then:
http://www.zsh.org/mla/workers/2019/msg00301.html though I don't
think any action was taken on that.

> > 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).

Thanks. Geoff was making it sound that that issue was already
settled (long before I raised that 1234 bug), and bash and
another shell have already implemented the new behaviour. I'm
glad there's still scope for discussion.


Reply via email to