Bug? Unexpected globbing duplicates

Bug? Unexpected globbing duplicates

[andykluger]

Hello!

I encountered a surprising result while using a glob expression, with
extended globs enabled, of duplicate resulting elements, where the
number of duplicates is proportional to the filesystem depth of that
result.

The expression I first observed this with pointlessly combines **/***/:

% vids=((#i)**/***/*(.mp4)(#q.))

Simply demonstrated, without extendedglob or qualifiers or flags:

% mkdir -p foo/bar/baz
% print -rl -- **/***/*

foo
foo/bar
foo/bar
foo/bar/baz
foo/bar/baz
foo/bar/baz

And thanks to danielsh and dana for pointing out, with **/**/:

% print -rl -- **/**/*

foo
foo/bar
foo/bar
foo/bar/baz
foo/bar/baz
foo/bar/baz

I know now there's no reason to have the extra leading **/ in either
case, and this problem does not present when done properly like that.

Thanks for reading,
Andy

Re: Bug? Unexpected globbing duplicates

[Bart Schaefer]

On Sat, Feb 12, 2022 at 12:32 PM <andykluger@gmail.com> wrote:
>
> I encountered a surprising result while using a glob expression, with
> extended globs enabled, of duplicate resulting elements
> [...]
> % print -rl -- **/**/*

The **/ operator is done by recursive descent, so if it appears more
than once it'll re-scan everything below the second (or third, etc.)
occurrence as the stack is unwound.  I suspect it'd make globbing
noticeably slower to check every new result against those already
found.  There might be a way to do it just for already-visited
directories that wouldn't add too much overhead.

It might also be possible for the glob-pattern parser to keep track of
when it's already seen **/ or (*/)# and treat further repetitions as
plain */ but that doesn't cover something like (*/)#(bar/)# ... I
suspect it's better to just do what the user wrote, there are other
ways to remove duplicates.