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 @(?|.?)      #. 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