Mon 03 Jan 2011 08:56:19 PM UTC, original submission:
On a Solaris machine:
$ /bin/find /usr/local/bin/ -name [
/usr/local/bin/[
$ /bin/find /usr/local/bin/ -name '\['
/usr/local/bin/[
$ find /usr/local/bin/ -name [
$ find /usr/local/bin/ -name '\['
/usr/local/bin/[
$ 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.
|