5

Is it a bug that, when I find ./path/here/ I get:

./path/here//foo
./path/here//bar

I know find wants me to specify the path without the trailing slash, but surely it can detect the path that tab-completing leaves me with and adjust its output accordingly. Is there any reason why it doesn't?

1
  • 4
    Submit a bug report to Apple. If enough people complain, they'll fix it. Nov 2, 2016 at 0:06

2 Answers 2

8

Technically, it's a bug, because POSIX states that

all pathnames for other files encountered in the hierarchy shall consist of the concatenation of the current path operand, a <slash> if the current path operand did not end in one, and the filename relative to the path operand

But the double slash doesn't make any difference, so ./path/here//foo and ./path/here/foo are always the same file. (A double slash does make a difference if it's at the start of the path on a few Unix variants. If yours does then hopefully find treats this case specially.)

1

For the record, one reason one might use find some/dir/ instead of find some/dir is when some/dir is actually a symlink to a directory and you do want find to find files in the directory pointed to by that symlink.

But, in that case, there's a better alternative:

find -H some/dir

-H is an option supported by a few POSIX utilities (ls, cp, chmod...) which tells the utility to follow symlinks passed as arguments (and just those, not to be confused with -L/-follow which causes find to follow every symlink, those passed as arguments but also those found during directory traversal).

That's still not functionally equivalent to find some/dir/ in the case where some/dir is actually not a directory. In that case, find some/dir/ would fail with a Not a directory error while find -H some/dir would list that non-directory file.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.