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?

Stéphane Chazelas
  • 544,893
Bobby Jack
  • 350

2 Answers2

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.)

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
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.

Stéphane Chazelas
  • 544,893