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 today (http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=48492ffae22d692594757e53fb4580ebb1f506cf) 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: pattern='\.' 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). and 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. -- Stephane
