bugfindutils - Bugs: bug #60540, enable extended shell patterns for...


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

Submitter:  Ian Bruce <ian_bruce>
Submitted:  Thu 06 May 2021 11:33:22 PM UTC
Category:  find Severity:  1 - Wish
Item Group:  None Status:  None
Privacy:  Public Assigned to:  berny
Originator Name:  Open/Closed:  Open
Release:  None Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Sun 06 Jun 2021 11:14:14 AM UTC, 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
[2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13

Therefore, adding the FNM_EXTMATCH flag to the standard -name/-iname options is
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 that
OTOH, find(1) already supports the -regex option as GNU extension with several
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 that
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 always
worthwhile - suggestions and patches welcome.

Have a nice day,

Bernhard Voelker <berny>
Group administrator
Thu 06 May 2021 11:33:22 PM UTC, original submission:  

The find(1) manual page states that for the "-name" test, "filename matching is performed with the use of the fnmatch(3) library function."

Referring to the manual page for that function, the following flag is specified:


    If this flag (a GNU extension) is set, extended patterns are supported, as introduced by 'ksh' and now supported by other shells. The extended format is as follows, with pattern-list being a '|' separated list of patterns.


    The pattern matches if exactly one occurrence of any of the patterns in the pattern-list match the input string.


However, it does not appear that this flag has been enabled for find(1) :

    $ ls
    videofile.avi  videofile.mkv  videofile.mp4  videofile.wmv

    $ ls *.@(mp4|avi)
    videofile.avi  videofile.mp4

    $ find . -name '*.@(mp4|avi)'
    [nothing found]

Please add this flag to the fnmatch() call, so that find(1) can produce the same matches as the shell would. Presumably, no other code changes would be required. Obviously, this flag should also be enabled for the "-iname" test.

If it is thought that enabling this functionality by default would be undesirable for some reason, consider adding "-extname" and "-iextname" tests which include it.

In any case, the find(1) manual page should be updated to explain whether or not these extended shell patterns are supported.

Thank you.

Ian Bruce <ian_bruce>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by ian_bruce (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-06 berny Severity3 - Normal 1 - Wish
        Assigned toNone berny

    Back to the top

    Powered by Savane 3.13-c54d.
    Corresponding source code