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 @(?|.?) #. and .. are included
. .. a .b
This does not. However, everything from hereon does.
$ shopt -u dotglob
$ echo ? ??
a ??
$ echo ? .? #even with dotglob off .. is still matched
a .. .b
That is to be expected. The applicable pattern begins with a literal dot.
$ echo @(?|??)
a
$ echo @(?|.?) #. is excluded but .. is included
.. a .b
Ditto.
$
--
Kerin Millar
