So I was having this weird problem where the results of Find command were coming back with a double slash in the file path.

After thinking I’d solved it and starting to write out the solution, I realized the issue was because my search target was a symbolic link. I then found Find’s switch for dealing with this problem. Doubtlessly someone else is or will come across this same issue, so I’ll explain what was happening anyway.

This all came up because I needed to grab a set of files that resided in my /tmp directory. On Mac OS X, tmp is actually a symbolic link (a unixy kind of alias) which points to /private/tmp.

Here are a few iterations of this command and a description of their results:

find /tmp -name 'Web*' -print

Returns nothing because find is searching /tmp as a file instead of following the link to the target directory.

find /tmp/ -name 'Web*' -print

This returns the files I was looking for, but their paths contained double slashes (ie. /tmp//Webkit...). The double-slashes were strange, and I suspected (wrongly, keep reading) that they might be causing problems with later commands.

find /tmp/* -name 'Web*' -print

This works, and returned correct file paths, but it probably uses shell expansion which seems silly on top of Find’s own abilities.

Reading the man page again, after the symbolic link realization, I finally saw the -H flag:

The -H option causes the file information and file type (see stat(2)) returned for each symbolic link specified on the command line to be those of the file referenced by the link, not the link itself. If the referenced file does not exist, the file information and type will be for the link itself. File information of all symbolic links not on the command line is that of the link itself.

Well that took a stupid amount of time to discover. Using -H, the command works perfectly with the simple /tmp target:

find -H /tmp -name 'Web*' -print

Same results as the /tmp/* line, but a much cleaner command.

A funny, or sad, footnote of this story is that my original problem had nothing to do with the double-slashed paths. I didn’t realize the files were owned by root and that was causing my command to fail.