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

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


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
flag.
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
./hayseed_dixie/hayseedstory.mov


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,
Berny

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60540>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/