Re: . and .. are included where they were excluded before
On 1/27/21 4:07 AM, pepa65 wrote: On 27/01/2021 14.49, k...@plushkava.net wrote: That's why your .? glob doesn't match the .. pathname. Normally, GLOBIGNORE isn't set. After unsetting GLOBIGNORE: That doesn't unset GLOBIGNORE. $ declare -p GLOBIGNORE declare -x GLOBIGNORE="" Depending on your environment, this may leave the dotglob option enabled. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: . and .. are included where they were excluded before
On 27/01/2021 14.49, k...@plushkava.net wrote:
> That's why your .? glob doesn't match the .. pathname. Normally,
> GLOBIGNORE isn't set.
After unsetting GLOBIGNORE:
$ declare -p GLOBIGNORE
declare -x GLOBIGNORE=""
$ shopt -u extglob
$ echo @(?|.?)
-bash: syntax error near unexpected token `('
$ shopt -s extglob
$ echo @(?|.?)
. ..
At any rate, the following command may help you to track
> down where it's coming from.
>
> $ PS4='+$BASH_SOURCE:$LINENO: ' bash -ixlc '' |& less
It turned out this was erroneously set in a profile...
Thanks,
Peter
Re: . and .. are included where they were excluded before
On 27/01/2021 07:38, pepa65 wrote: On 27/01/2021 14.30, k...@plushkava.net wrote: Note that declare -p BASH_VERSION would report the version of bash that you're currently running interactively. $ declare -p BASH_VERSION declare -- BASH_VERSION="5.0.17(1)-release" Does declare -p GLOBIGNORE show that the variable is set? Does echo $- show the letter 'f' anywhere? $ declare -p GLOBIGNORE declare -x GLOBIGNORE=".." That's why your .? glob doesn't match the .. pathname. Normally, GLOBIGNORE isn't set. echo $- himBs No f, and GLOBIGNORE stays the same whether I do `shopt -s extglob` or `shopt -u extglob`... So probably ignore my results. But I would like to know what could be wrong with this system/install. You may use the unset builtin to unset the GLOBIGNORE variable, or run bash with the --norc option to obtain the standard behaviour. I find it unlikely that Ubuntu would have chosen to interfere with this variable by default. At any rate, the following command may help you to track down where it's coming from. $ PS4='+$BASH_SOURCE:$LINENO: ' bash -ixlc '' |& less -- Kerin Millar
Re: . and .. are included where they were excluded before
On 27/01/2021 14.30, k...@plushkava.net wrote: > Note that declare -p BASH_VERSION would report the version of bash that > you're currently running interactively. $ declare -p BASH_VERSION declare -- BASH_VERSION="5.0.17(1)-release" > Does declare -p GLOBIGNORE show that the variable is set? Does echo $- > show the letter 'f' anywhere? $ declare -p GLOBIGNORE declare -x GLOBIGNORE=".." echo $- himBs No f, and GLOBIGNORE stays the same whether I do `shopt -s extglob` or `shopt -u extglob`... So probably ignore my results. But I would like to know what could be wrong with this system/install. Thanks, Peter
Re: . and .. are included where they were excluded before
On 27/01/2021 06:50, pepa65 wrote: On 27/01/2021 04.00, k...@plushkava.net wrote: One example is that gregrwm claims the following outcome for 5.0.17(1) in Ubuntu 20.04:- $ echo @(?|.?) #. and .. are included . .. a .b $ cat /etc/issue Ubuntu 20.04.1 LTS \n \l $ bash --version GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) [...] Note that declare -p BASH_VERSION would report the version of bash that you're currently running interactively. $ shopt -s extglob $ echo @(?|.?) @(?|.?) (I don't know, is there something wrong with my bash? Do I have to set other options??) Does declare -p GLOBIGNORE show that the variable is set? Does echo $- show the letter 'f' anywhere? -- Kerin Millar
Re: . and .. are included where they were excluded before
On 27/01/2021 04.00, k...@plushkava.net wrote: > One example is that gregrwm claims the following outcome for 5.0.17(1) > in Ubuntu 20.04:- > > $ echo @(?|.?) #. and .. are included > . .. a .b $ cat /etc/issue Ubuntu 20.04.1 LTS \n \l $ bash --version GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) [...] $ shopt -s extglob $ echo @(?|.?) @(?|.?) (I don't know, is there something wrong with my bash? Do I have to set other options??) Peter
Re: . and .. are included where they were excluded before
On 2021/01/26 09:08, Chet Ramey wrote: That's the real question: whether or not `.' should match @(?|.?), even when dotglob is enabled (and yes, both patterns have to be in there). There isn't really any other. Since it doesn't match ? when dotglob is enabled, there's an obvious inconsistency there, and that's what I'll look at. I don't see it as being inconsistent, since shopt -u dotglob will match the literal 1st byte (dot). From there we are no longer looking at "default behavior for "." to match '?' but at normal "glob-RE" rules. .foo won't be match by , but will be matched by .??? Note, it's not just about . and .., all files starting with 1 or 2 dots.
Re: . and .. are included where they were excluded before
On 1/26/21 4:00 PM, k...@plushkava.net wrote: One example is that gregrwm claims the following outcome for 5.0.17(1) in Ubuntu 20.04:- $ echo @(?|.?) #. and .. are included . .. a .b Note that '.' is said to be among the pathnames matched. I don't see how this can possibly be the case. I'm hoping that it was merely a case of making a mistake in the course of performing the tests and assembling the results. That's the thing I said I would look at in my initial message. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: . and .. are included where they were excluded before
On 26/01/2021 21:13, Chet Ramey wrote: On 1/26/21 4:00 PM, k...@plushkava.net wrote: One example is that gregrwm claims the following outcome for 5.0.17(1) in Ubuntu 20.04:- $ echo @(?|.?) #. and .. are included . .. a .b Note that '.' is said to be among the pathnames matched. I don't see how this can possibly be the case. I'm hoping that it was merely a case of making a mistake in the course of performing the tests and assembling the results. That's the thing I said I would look at in my initial message. Ah, I see. I'll stop fretting over it then. -- Kerin Millar
Re: . and .. are included where they were excluded before
On 26/01/2021 20:49, Chet Ramey wrote: On 1/26/21 3:27 PM, k...@plushkava.net wrote: 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. Don't be. CentOS is running a version of bash-4.2 (without even all of the patches applied); that version was released more than ten years ago and the changes we're talking about here came in between bash-4.2 and bash-4.3. Thanks, Chet. Still, the original post mentions an anomaly or two that supposedly apply to more recent versions (4.4.19 and 5.0.17) and it is those that have been bothering me especially. I called them out in my original reply. One example is that gregrwm claims the following outcome for 5.0.17(1) in Ubuntu 20.04:- $ echo @(?|.?) #. and .. are included . .. a .b Note that '.' is said to be among the pathnames matched. I don't see how this can possibly be the case. I'm hoping that it was merely a case of making a mistake in the course of performing the tests and assembling the results. -- Kerin Millar
Re: . and .. are included where they were excluded before
On 1/26/21 2:34 PM, gregrwm wrote: you're calling .. an explicit match to .? Yes: the leading `.' is explicitly included. i'd interpret explicit match to mean .. wouldn't match anything other than itself (notwithstanding it's been otherwise for over a decade) That's not a glob pattern. There are patterns that can match `.' and `..'; `.*' still matches both, for instance. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: . and .. are included where they were excluded before
On 1/26/21 3:27 PM, k...@plushkava.net wrote: 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. Don't be. CentOS is running a version of bash-4.2 (without even all of the patches applied); that version was released more than ten years ago and the changes we're talking about here came in between bash-4.2 and bash-4.3. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: . and .. are included where they were excluded before
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
Re: . and .. are included where they were excluded before
> > > . 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 .? i'd interpret explicit match to mean .. wouldn't match anything other than itself (notwithstanding it's been otherwise for over a decade) > 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
Re: . and .. are included where they were excluded before
On 1/25/21 4:36 PM, gregrwm wrote: Bash Version: 5.0 Patch Level: 17 Release Status: release Description: . 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). is this change in functionality a regression, a "fix", or a new feature? is there any option to exclude them? We're talking about behavior that changed around ten years ago, so there's probably no going back. in all 3, .. is included in .? Yes, basically every shell except mksh does this. The leading dot is matched explicitly. so oddly in centos7 .. is included in .? but excluded from @(?|.?) CentOS is using a version of bash that's over ten years old. and in the more recent versions it's a different inconsistency, . is excluded from ? ?? but included in @(?|.?) That's the real question: whether or not `.' should match @(?|.?), even when dotglob is enabled (and yes, both patterns have to be in there). There isn't really any other. Since it doesn't match ? when dotglob is enabled, there's an obvious inconsistency there, and that's what I'll look at. 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. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: . and .. are included where they were excluded before
On 26/01/2021 13:04, Lawrence Velázquez wrote: On Jan 26, 2021, at 12:51 AM, "" wrote: On 25/01/2021 21:36, gregrwm wrote: is this change in functionality a regression, a "fix", or a new feature? is there any option to exclude them? in all 3, .. is included in .? This seems to be as expected. The pattern must begin with a literal dot in order to match either of the pathnames '.' and '..'. This holds true, irrespective of whether or not dotglob is enabled. Ergo, a pattern of ? should not match the pathname '.', whereas a pattern of .? can - and will - match the pathname '..'. Similarly, a pattern of .* would match both '.' and '..'. 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. I would summarise the implications of the report as follows. Firstly, ? should never match '.' because of the constraint described by the sentence preceding the one you quoted. Secondly, the matter of whether a given pattern is contained by a @(pattern-list) should not influence the behaviour of said pattern. In particular, @(?|.?) should never ignore '..', owing to the presence of the .? pattern which explictly matches. The OP has indicated that these two assurances do not collectively hold for the systems on which he is testing (they do for all the systems that I have). Therein lies the rub. -- Kerin Millar
Re: . and .. are included where they were excluded before
> On Jan 26, 2021, at 12:51 AM, "" > wrote: > >> On 25/01/2021 21:36, gregrwm wrote: >> >> is this change in functionality a regression, a "fix", or a new >> feature? >> is there any option to exclude them? >> in all 3, .. is included in .? > > This seems to be as expected. The pattern must begin with a literal dot in > order to match either of the pathnames '.' and '..'. This holds true, > irrespective of whether or not dotglob is enabled. > > Ergo, a pattern of ? should not match the pathname '.', whereas a pattern of > .? can - and will - match the pathname '..'. Similarly, a pattern of .* would > match both '.' and '..'. 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
Re: . and .. are included where they were excluded before
On 25/01/2021 21:36, gregrwm wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux e540 5.4.0-60-generic #67-Ubuntu SMP Tue Jan 5 18:31:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 17 Release Status: release Description: . and .. are excluded from @(?|.?) in bash 4.2.46(2)-release (CentOS 7.8), but are included > bash 4.4.19(1)-release (CentOS 8.2) and bash 5.0.17(1)-release (Ubuntu 20.04/focal). For a pattern of ? to match '.' is concerning. is this change in functionality a regression, a "fix", or a new feature? is there any option to exclude them? in all 3, .. is included in .? This seems to be as expected. The pattern must begin with a literal dot in order to match either of the pathnames '.' and '..'. This holds true, irrespective of whether or not dotglob is enabled. Ergo, a pattern of ? should not match the pathname '.', whereas a pattern of .? can - and will - match the pathname '..'. Similarly, a pattern of .* would match both '.' and '..'. That said, I do not understand why 4.2 behaved differently. so oddly in centos7 .. is included in .? but excluded from @(?|.?) and in the more recent versions it's a different inconsistency, . is excluded from ? ?? but included in @(?|.?) I understand that you meant to write ? .? there. Under no circumstances am I able to have ? match '.' with the systems that I have to hand, whether it be part of an extglob or not. None of them are running CentOS, however. As such, I think that this is the most worrying aspect of your report. Hopefully, Chet will have some idea of what might be going on in your case. 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). You can achieve that by manipulating GLOBIGNORE. Here is a demonstration. $ mkdir testdir $ cd testdir $ shopt -s failglob $ echo .* . .. $ GLOBIGNORE=. $ echo .* -bash: no match: .* As setting GLOBIGNORE to a non-empty value also has the effect of enabling dotglob, there is still the possibility of a glob beginning with a dot matching other pathnames that begin with a dot. Even this may be prevented, as shown below. $ : carrying on from where we left off ... $ touch .x $ unset GLOBIGNORE $ echo .* . .. .x $ GLOBIGNORE=. $ echo .* .x $ GLOBIGNORE=.* $ echo .* -bash: no match: .* Repeat-By: $ echo $BASH_VERSION 4.2.46(2)-release $ cat /etc/centos-release CentOS Linux release 7.8.2003 (Core) $ echo $BASHOPTS checkwinsize:cmdhist:dotglob:expand_aliases:extglob:extquote:force_fignore:globstar:histappend:histreedit:histverify:hostcomplete:interactive_comments:nocaseglob:nocasematch:progcomp:promptvars $ touch a .b $ echo ? ?? a .b $ echo ? .? #.. is included a .. .b This seems fine. $ echo @(?|??) a .b $ echo @(?|.?) #. and .. are excluded a .b This does not, because .? should have matched '..'. $ $ echo $BASH_VERSION 4.4.19(1)-release $ cat /etc/centos-release CentOS Linux release 8.2.2004 (Core) $ echo $BASHOPTS checkwinsize:cmdhist:complete_fullquote:dotglob:expand_aliases:extglob:extquote:force_fignore:globstar:histappend:histreedit:histverify:hostcomplete:interactive_comments:nocaseglob:nocasematch:progcomp:promptvars $ touch a .b $ echo ? ?? a .b $ echo ? .? #.. is included a .. .b $ echo @(?|??) a .b This seems fine. $ echo @(?|.?) #. and .. are included . .. a .b This does not. I don't understand how '.' is matched there. $ $ echo $BASH_VERSION 5.0.17(1)-release $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS" $ echo $BASHOPTS checkwinsize:cmdhist:complete_fullquote:dotglob:expand_aliases:extglob:extquote:force_fignore:globasciiranges:globstar:histappend:histreedit:histverify:interactive_comments:login_shell:nocaseglob:nocasematch:progcomp:p $ touch a .b $ echo ? ?? a .b $ echo ? .? #.. is included a .. .b $ echo @(?|??) a .b This seems fine. $ echo @(?|.?)
Re: . and .. are included where they were excluded before
sorry, typo: and in the more recent versions it's a different inconsistency, . is excluded from ? ?? but included in @(?|.?) should be: and in the more recent versions it's a different inconsistency, . is excluded from ? .? but included in @(?|.?) tho as i said that's a tad askew from... On Mon, Jan 25, 2021 at 3:36 PM gregrwm wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. -fstack-protector-strong > -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security > uname output: Linux e540 5.4.0-60-generic #67-Ubuntu SMP Tue Jan 5 > 18:31:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.0 > Patch Level: 17 > Release Status: release > > Description: > . 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). > > is this change in functionality a regression, a "fix", or a new > feature? > is there any option to exclude them? > > in all 3, .. is included in .? > > so oddly in centos7 .. is included in .? but excluded from @(?|.?) > > and in the more recent versions it's a different inconsistency, . > is excluded from ? ?? but included in @(?|.?) > > 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). > > Repeat-By: > $ echo $BASH_VERSION > 4.2.46(2)-release > $ cat /etc/centos-release > CentOS Linux release 7.8.2003 (Core) > $ echo $BASHOPTS > > checkwinsize:cmdhist:dotglob:expand_aliases:extglob:extquote:force_fignore:globstar:histappend:histreedit:histverify:hostcomplete:interactive_comments:nocaseglob:nocasematch:progcomp:promptvars > $ touch a .b > $ echo ? ?? > a .b > $ echo ? .? #.. is included > a .. .b > $ echo @(?|??) > a .b > $ echo @(?|.?) #. and .. are excluded > a .b > $ > > $ echo $BASH_VERSION > 4.4.19(1)-release > $ cat /etc/centos-release > CentOS Linux release 8.2.2004 (Core) > $ echo $BASHOPTS > > checkwinsize:cmdhist:complete_fullquote:dotglob:expand_aliases:extglob:extquote:force_fignore:globstar:histappend:histreedit:histverify:hostcomplete:interactive_comments:nocaseglob:nocasematch:progcomp:promptvars > $ touch a .b > $ echo ? ?? > a .b > $ echo ? .? #.. is included > a .. .b > $ echo @(?|??) > a .b > $ echo @(?|.?) #. and .. are included > . .. a .b > $ > > $ echo $BASH_VERSION > 5.0.17(1)-release > $ cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=20.04 > DISTRIB_CODENAME=focal > DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS" > $ echo $BASHOPTS > > checkwinsize:cmdhist:complete_fullquote:dotglob:expand_aliases:extglob:extquote:force_fignore:globasciiranges:globstar:histappend:histreedit:histverify:interactive_comments:login_shell:nocaseglob:nocasematch:progcomp:p > $ touch a .b > $ echo ? ?? > a .b > $ echo ? .? #.. is included > a .. .b > $ echo @(?|??) > a .b > $ echo @(?|.?) #. and .. are included > . .. a .b > $ shopt -u dotglob > $ echo ? ?? > a ?? > $ echo ? .? #even with dotglob off .. is still matched > a .. .b > $ echo @(?|??) > a > $ echo @(?|.?) #. is excluded but .. is included > .. a .b > $ >
. and .. are included where they were excluded before
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux e540 5.4.0-60-generic #67-Ubuntu SMP Tue Jan 5 18:31:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 17 Release Status: release Description: . 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). is this change in functionality a regression, a "fix", or a new feature? is there any option to exclude them? in all 3, .. is included in .? so oddly in centos7 .. is included in .? but excluded from @(?|.?) and in the more recent versions it's a different inconsistency, . is excluded from ? ?? but included in @(?|.?) 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). Repeat-By: $ echo $BASH_VERSION 4.2.46(2)-release $ cat /etc/centos-release CentOS Linux release 7.8.2003 (Core) $ echo $BASHOPTS checkwinsize:cmdhist:dotglob:expand_aliases:extglob:extquote:force_fignore:globstar:histappend:histreedit:histverify:hostcomplete:interactive_comments:nocaseglob:nocasematch:progcomp:promptvars $ touch a .b $ echo ? ?? a .b $ echo ? .? #.. is included a .. .b $ echo @(?|??) a .b $ echo @(?|.?) #. and .. are excluded a .b $ $ echo $BASH_VERSION 4.4.19(1)-release $ cat /etc/centos-release CentOS Linux release 8.2.2004 (Core) $ echo $BASHOPTS checkwinsize:cmdhist:complete_fullquote:dotglob:expand_aliases:extglob:extquote:force_fignore:globstar:histappend:histreedit:histverify:hostcomplete:interactive_comments:nocaseglob:nocasematch:progcomp:promptvars $ touch a .b $ echo ? ?? a .b $ echo ? .? #.. is included a .. .b $ echo @(?|??) a .b $ echo @(?|.?) #. and .. are included . .. a .b $ $ echo $BASH_VERSION 5.0.17(1)-release $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS" $ echo $BASHOPTS checkwinsize:cmdhist:complete_fullquote:dotglob:expand_aliases:extglob:extquote:force_fignore:globasciiranges:globstar:histappend:histreedit:histverify:interactive_comments:login_shell:nocaseglob:nocasematch:progcomp:p $ touch a .b $ echo ? ?? a .b $ echo ? .? #.. is included a .. .b $ echo @(?|??) a .b $ echo @(?|.?) #. and .. are included . .. a .b $ shopt -u dotglob $ echo ? ?? a ?? $ echo ? .? #even with dotglob off .. is still matched a .. .b $ echo @(?|??) a $ echo @(?|.?) #. is excluded but .. is included .. a .b $
