@MSGID: <rq5atj-sh92.ln1@wilbur.25thandClement.com>
daa7b7be
@REPLY: <20230912101332.94@kylheku.com> 4e026aee
@REPLYADDR William Ahern
<william@25thandClement.com>
@REPLYTO 2:5075/128 William Ahern
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<rq5atj-sh92.ln1@wilbur.25thandClement.com>
@RFC-References: <20230911202309.171@kylheku.com>
<20230911234401.851@kylheku.com> <20230912101332.94@kylheku.com>
@TZUTC: -0700
@PID: tin/2.4.4-20191224 ("Millburn") (OpenBSD/7.3
(amd64))
@TID: FIDOGATE-5.12-ge4e8b94
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-09-12, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> On 2023-09-12, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>> The real function should handle patterns starting with "**/" and also
>>> ending in "/**", as well as when "**" is the entire pattern.
>>
>> I fixed this in the prototype.
> 
> Issues:

> 
> 2.  Escaping
> 
>     The interior /**/ pattern could occur in a class like [abc/**/def]
>     in which case it must not be recognized.

FWIW, OpenBSD sh seems not to tolerate slashes in bracket expressions:

  $ ls *          
  bar      foo      foo*bar
  $ ls *[*]*
  foo*bar
  $ ls *[*z]*
  foo*bar
  $ ls *[*/]*  
  ls: *[*/]*: No such file or directory

It seems to be [recursively] splitting on slash before pattern matching on
filenames. See line 1086 in globit at
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/ksh/eval.c?annotate=1.67

And this behavior seems to be POSIX compliant:

  2.13.3 Patterns Used for Filename Expansion
  
  The rules described so far in Patterns Matching a Single Character and
  Patterns Matching Multiple Characters are qualified by the following rules
  that apply when pattern matching notation is used for filename expansion:

  1. The  character in a pathname shall be explicitly matched by
     using one or more  characters in the pattern; it shall neither
     be matched by the  or  special characters nor
     by a bracket expression.  characters in the pattern shall be
     identified before bracket expressions; thus, a  cannot be
     included in a pattern bracket expression used for filename expansion.

At first I was wondering why you thought you could get away with merely
scanning for slash+double-star and double-star+slash--bracket expressions
obviously require stateful parsing. But clearly POSIX anticipates (or even
expects) that shells would process slashes before parsing component
patterns. I believe this allowance/limitation would likewise apply to
glob(3), which specially mentions rule #3 under 2.13.3; unlike case and
fnmatch(3), which are normally used for generic string matching.

But I guess none of that is helpful if you`re trying to match some
sophisticated Bash behavior.
--- tin/2.4.4-20191224 ("Millburn")  (OpenBSD/7.3 (amd64))
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5010/352 5015/255 5019/40
5020/715 848 1042 4441
SEEN-BY: 5020/12000 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441