On 26/01/2021 19:34, gregrwm wrote:
. and .. are excluded from @(?|.?) in
bash 4.2.46(2)-release (CentOS 7.8), but are included in
bash 4.4.19(1)-release (CentOS 8.2) and
bash 5.0.17(1)-release (Ubuntu 20.04/focal).
According to the manual, "[t]he filenames ‘.’ and ‘..’ must always be
matched explicitly even if dotglob is set." I don't see any subsequent
text that overrules this for extended globs.
https://www.gnu.org/software/bash/manual/html_node/Filename-Expansion.html
vq
Indeed, nor should you... @(?|.?) should never ignore '..', owing to the
presence of the .? pattern which explictly matches...
--
Kerin Millar
you're calling .. an explicit match to .?
Yes, I am. It's in line with the various sh(1) implementations also.
What makes the pathnames . and .. special is that a glob must begin with
a literal dot to match them by way of pathname expansion. That much, I
think, is explained adequately by the manual. Enabling dotglob doesn't
affect this constraint.
I'm still worried about some of the curious results shown by your
original post but I haven't had a chance to test the same platforms yet.
I can easily imagine CentOS 7.2 being buggy; not so much in the case of
the other two operating systems that you mention.
i'd interpret explicit match to mean .. wouldn't match anything other than
itself (notwithstanding it's been otherwise for over a decade)
In isolation, .. isn't a glob. It won't be subjected to pathname
expansion and thus, there's nothing to even 'match'. Rather, it will
always be taken literally.
Still, I can see how the import of the present wording might not be
fully understood upon first reading. Perhaps it could be tweaked a little.
but that's a bit askew from what actually interests me. if i had
my druthers, there would be an option to set so . and .. would never
match
any (sub)glob other than their literal selves (even with dotglob set).
As Kerin Millar said, you can use GLOBIGNORE for this.
indeed that's exactly what i was looking for, thank you lawrence, kerin,
and chet
--
Kerin Millar
