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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to