Find Command – How Does find -name Work with Regular Expressions

findregular expression

I can't for the life of me figure out how find with the test -name works.

I run find / -name *in and returns a bunch of results:

/sbin
/sbin/sulogin
/dev/stdin

to name a few.

It's as if it performed filename expansion, but that happens before the shell runs the command, so that can't be it. Also because I don't have any files in the current directory that match *in. Plus, single quoting *in yields the same results, which further supports that this can't be filename expansion.

The documentation leads me to believe that find with -name uses regular expressions, but the regex pattern *in doesn't match the results I showed above.

Can someone enlighten me?

Best Answer

The parameter passed to -name is a filesystem glob pattern, the same as the you'd enter for other commands, such as ls -l *in.

For each file it finds it compares the basename of the file to the pattern you passed. So when it finds /bin/foobar it compares foobar to *in, doesn't match, skips; but with /bin/login it compares login to *in and this does match, and so prints.

Now you need to be careful because *in might be matched on the command line depending on files in the current directory.

So, for example:

$ find /bin -name *in
/bin
/bin/login

$ touch foobarin

$ find /bin -name *in
$

Notice the same find command returned two different results.

We can see why if we set the shell to debug mode:

$ rm foobarin 

$ set -x

$ find /bin -name *in
+ find /bin -name '*in'
/bin
/bin/login

$ touch foobarin     
+ touch foobarin

$ find /bin -name *in
+ find /bin -name foobarin

$

The lines starting with a + are what the shell interpreted the command entered. We can see that the second find command expanded the *in to match the existing filename.

Because of this it's recommended to quote names

$ find /bin -name '*in'
+ find /bin -name '*in'
/bin
/bin/login

Related Solutions

CentOS Files – How to Rename All Files with a Certain Name

rename stringx stringy stringx.*

There are (at least) two utilities called rename on typical Linux systems. Debian and derived distributions (including Ubuntu) ship a Perl script whose syntax would be

rename 's/stringx/stringy/' stringx.*

On other distributions, including CentOS, rename is from util-linux, and its syntax is what I wrote above. This utility is available under the name rename.ul on Debian and derivatives.

If you want to recurse in subdirectories, assuming that by csh you mean tcsh (but really, think of entering the mid-1990s and switching to zsh):

set globstar
rename stringx stringy stringx.* **/stringx.*

Bash – Filename Expansion: Find Utility Pattern Matching vs Bash Shell Pattern Matching

In the shell, you need to distinguish filename generation/expansion (aka globbing: a pattern that expands to a list of files) from pattern matching. globbing uses pattern matching internally, but it's really before all an operator to generate a list of files based on a pattern.

*/*.txt is a pattern which matches a sequence of 0 or more characters, followed by /, followed by a sequence of zero or more characters, followed by .txt. When used as a shell pattern as in:

case $file in
  */*.txt) echo match
esac

It will match on file=.foo/bar/baz.txt.

However, */*.txt as a glob is something related but more complex.

In expanding */*.txt into a list of files, the shell will open the current directory, list its content, find the non-hidden files of type directory (or symlink to directory) that match *, sort that list, open each of those, list their content, and find the non-hidden ones that match *.txt.

It will never expand .foo/bar/bar.txt even though that matches the pattern because that's not how it works. On the other hand, the file paths generated by a glob will all match that pattern.

Similarly, a glob like foo[a/b]baz* will find all the files whose name starts with b]baz in the foo[a directory.

So, we've seen already that for globbing, but not for pattern matching, / is special (globs are somehow split on / and each part treated separately) and dot-files are treated specially.

Shell globbing and pattern matching are part of the shell syntax. It's intertwined with quoting and other forms of expansion.

$ bash -c 'case "]" in [x"]"]) echo true; esac'
true

Quoting that ] removes its special meaning (of closing the previous [):

It can be even more confusing when you mix everything:

$ ls
*  \*  \a  x

$ p='\*' ksh -xc 'ls $p'
+ ls '\*' '\a'
\*  \a

OK \* is all the files starting with \.

$ p='\*' bash -xc 'ls $p'
+ ls '\*'
\*

It's not all the files starting with \. So, somehow, \ must have escaped the *, but then again it's not matching * either...

For find, it's a lot simpler. find descends the directory tree at each of the file argument it receives and then do the tests as instructed for each encountered file.

For -type f, that's true if the file is a regular file, false otherwise for -name <some-pattern>, that's true if the name of the currently considered file matches the pattern, false otherwise. There's no concept of hidden file or / handling or shell quoting here, that's just matching a string (the name of the file) against a pattern.

So for instance, -name '*foo[a/b]ar' (which passes -name and *foo[a/b]ar arguments to find) will match foobar and .fooaar. It will never match foo/bar, but that's because -name matches on the file name; it would with -path instead.

Now, there is one form of quoting/escaping -- for find -- recognised here, and that's only with backslash. That allows to escape operators. For the shell, it's done as part of the usual shell quoting (\ is one of the shell's quoting mechanisms). For find (fnmatch()), that's part of the pattern syntax.

For instance, -name '\**' would match on files whose name starts with *. -name '*[\^x]*' would match on files whose name contains ^ or x...

Now, as for the different operators recognised by find, fnmatch(), bash and various other shells, they should all agree at least on a common subset: *, ? and [...].

Whether a particular shell or find implementation uses the system's fnmatch() function or their own is up to the implementation. GNU find does at least on GNU systems. Shells are very unlikely to use them as it would make things complicated for them and not worth the effort.

bash certainly doesn't. Modern shells like ksh, bash, zsh also have extensions over *, ?, [...] and a number of options and special parameters (GLOBIGNORE/FIGNORE) to affect their globbing behaviour.

Also note that beside fnmatch() which implements shell pattern matching, there's also the glob() function that implements something similar to shell globbing.

Now, there can be subtle differences between the pattern matching operators in those various implementations.

For instance, for GNU fnmatch(), ?, * or [!x] would not match a byte or sequence of bytes that don't form valid characters while bash (and most other shells) would. For instance, on a GNU system, find . -name '*' may fail to match files whose name contains invalid characters, while bash -c 'echo *' will list them (as long as they don't start with .).

We've mentioned already the confusion that can be incurred by quoting.

Best Answer

Related Solutions

CentOS Files – How to Rename All Files with a Certain Name

Bash – Filename Expansion: Find Utility Pattern Matching vs Bash Shell Pattern Matching

Related Question