@MSGID: <c08atj-0322.ln1@wilbur.25thandClement.com>
81feed9f
@REPLY: <rq5atj-sh92.ln1@wilbur.25thandClement.com>
daa7b7be
@REPLYADDR William Ahern
<william@25thandClement.com>
@REPLYTO 2:5075/128 William Ahern
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<c08atj-0322.ln1@wilbur.25thandClement.com>
@RFC-References: <20230911202309.171@kylheku.com>
<20230911234401.851@kylheku.com> <20230912101332.94@kylheku.com>
<rq5atj-sh92.ln1@wilbur.25thandClement.com>
@TZUTC: -0700
@PID: tin/2.4.4-20191224 ("Millburn") (OpenBSD/7.3
(amd64))
@TID: FIDOGATE-5.12-ge4e8b94
William Ahern <william@25thandclement.com> wrote:
> 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.
> 

> 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.

I`m glad I dug into this as I may have missed this caveat several years ago
when experimenting with a recursive glob command in POSIX shell:

  https://25thandClement.com/~william/2023/glob.sh

The recursion is implemented by recursively appending `*/` to the directory
prefix, rather than with an in-pattern construct, either because I forgot
about the `/**/` extension or assumed it wasn`t possible without more
cumbersome, stateful parsing of the pattern string. Though most of the
implementation is preoccupped with how to safely communicate filenames with
special characters--particularly whitespace--through pipelines using only
fast shell commands like printf (as opposed to od).

I wish I had pushed this up to GitHub as I rely on the (sh) printf %b format
specifier for decoding encoded filenames. POSIX sh printf %b clashes with
the newly defined %b in C2x. There`s a discussion on the Open Group
mailing-list about whether POSIX 202x/SuSv5 should deprecate %b, and someone
did a query across GitHub code only to find that almost all the usages of %b
are the same copy-pasted code which could be easily replaced if POSIX
deprecated/removed the old %b specifier.
--- 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