[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #60540] enable extended shell patterns for -name and -iname tests

From: Bernhard Voelker
Subject: [bug #60540] enable extended shell patterns for -name and -iname tests
Date: Sun, 6 Jun 2021 07:14:15 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Update of bug #60540 (project findutils):

                Severity:              3 - Normal => 1 - Wish               
             Assigned to:                    None => berny                  


Follow-up Comment #1:

Thanks for the suggestion.

First of all, despite I'm using the shell quite a lot, I've never used the
"@(...)" notation myself.

The POSIX specification [1] is quite clear about the pattern matching of the
-name option:

-name  pattern
    The primary shall [...] using the pattern matching notation described in
    Pattern Matching Notation.  The additional rules in Patterns Used for
    Filename Expansion do not apply as this is a matching operation, not an

The "Pattern Matching Notation" [2] in turn only foresees the question mark
the asterisk '*' and the left square bracket '[' as special characters with a
special meaning.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html

Therefore, adding the FNM_EXTMATCH flag to the standard -name/-iname options
impossible.  Furthermore, changing the behavior would/could break existing
scripts relying on the specified pattern matching.

Regarding adding another option for FNM_EXTMATCH:

The fnmatch(3) manual page states that FNM_EXTMATCH is a GNU extension.
Luckily, the gnulib module findutils is pulling in - fnmatch-gnu - supports
OTOH, find(1) already supports the -regex option as GNU extension with
modes (as defined by -regextype) which allow alternative pattern matching,
e.g. with the standard regex mode:

$ find . -regex '.*?\(mp4\|avi\|mov\)$' -print -quit

As no-one else voted for the FNM_EXTMATCH feature at all, I therefore think
the given -regex functionality seems to be sufficient; and introducing yet
another way to specify file name patterns may possibly confuse the users more
than it helps.
I'm therefore changing the severity to 'wish'.

Still, I believe improving the documentation to clarify the behavior is
worthwhile - suggestions and patches welcome.

Have a nice day,


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]