[Top][All Lists]

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

[bug #32043] find -name [ doesn't obey posix

From: Eric Blake
Subject: [bug #32043] find -name [ doesn't obey posix
Date: Mon, 03 Jan 2011 20:56:20 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.6.13-1.fc14 Firefox/3.6.13


                 Summary: find -name [ doesn't obey posix
                 Project: findutils
            Submitted by: ericb
            Submitted on: Mon 03 Jan 2011 01:56:19 PM MST
                Category: find
                Severity: 3 - Normal
              Item Group: Wrong result
                  Status: Confirmed
                 Privacy: Public
             Assigned to: None
         Originator Name: Eric Blake
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.5.9
           Fixed Release: None



On a Solaris machine:

$ /bin/find /usr/local/bin/ -name [
$ /bin/find /usr/local/bin/ -name '\['
$ find /usr/local/bin/ -name [
$ find /usr/local/bin/ -name '\['
$ find --version | head -n1
find (GNU findutils) 4.5.9

The third command demonstrates the bug in GNU find.  Find can (and should
continue to) locate [ when it was specified with quoting, but POSIX also
clearly states that an unmatched [ should be treated as a literal file name,
rather than rejected as an invalid glob, as follows:

Line 89090 states that find -name matches according to XBD 2.13 (but not
2.13.3, since it is a match and not a filename expansion).  And XBD 2.13, line
73748 states:

[ If an open bracket introduces a bracket expression as in XBD Section 9.3.5
(on page 184), except that the <exclamation-mark> character (’!’) shall
replace the <circumflex> character (’ˆ’) in its role in a non-matching
list in the regular expression notation, it shall introduce a pattern bracket
expression. A bracket expression starting with an unquoted <circumflex>
character produces unspecified results. Otherwise, ’[’ shall match the
character itself.

Since [ is not matched by ], it is not a bracket expression, therefore, it
shall match [ itself without requiring escaping.  It should not be necessary
to write -name '\[', when -name [ should do the same thing.

This may represent an even more fundamental bug in glibc and/or gnulib's
fnmatch() implementation, although I'd have to step through the find code to
state that for sure.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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