On 6/21/19 4:00 PM, Stephane Chazelas wrote: >> 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.
The sad part will be if the behavior controlled by 'set -o posixglob' or 'shopt -s posixglob' (I haven't yet checked which of the two means Chet added it under) will actually be setting behavior NOT specified by POSIX, depending on how this current thread plays out. And even if he leaves in a knob, I hope that the default for that knob when bash is invoked as /bin/sh is historical behavior (what bash decides to default to in bash mode is a different matter). But as long as it remains on Chet's development branch and not a 5.1 release or an official patch to 5.0, there's still time for Chet to change it... > > 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). Where's the glob character that causes $pattern to be subjected to globbing? Had there also been a '*', '[', or '?' in $pattern, I could (sort of) see the logic to the unquoted $pattern being subjected to use as a glob pattern. But when there are no globbing characters at all, why does \. suddenly serve to cause a glob lookup (where \ is then erased by the globbing procedure) and match '.' in the current directory? (And yes, this one is also confusing because of the ongoing work on the other open bug about whether shells should be permitted to always omit '.' from globbing, regardless of whether readdir() omitted it) > > 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. And that is indeed the regression in behavior, which seems to not be the historical practice of any earlier shell. If the standard has to permit bash 5 behavior by leaving it unspecified, we've still rendered a lot of existing scripts broken; better would be if we can agree on standard wording (and Chet updates bash 5 to match) to do what has traditionally been done of NOT globbing a sequence that does not contain '*', '[' or '?'. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Description: OpenPGP digital signature