次のような場合、これはバグでしょうかfind ./path/here/:
./path/here//foo
./path/here//bar
末尾のスラッシュなしでパスを指定する必要があることはわかっていますfindが、タブ補完によって残されたパスを検出し、それに応じて出力を調整できるはずです。そうしない理由はあるのでしょうか?
答え1
技術的には、それはバグです。POSIXの状態それ
階層内で遭遇する他のファイルのパス名はすべて、現在のパスオペランドと<スラッシュ>の連結で構成されるものとする。現在のパスオペランドが1で終わっていない場合、およびパスオペランドに対するファイル名の相対値
しかし二重スラッシュは意味がないなので、./path/here//fooと は./path/here/foo常に同じファイルです。(一部の Unix 系 OS では、パスの先頭に二重スラッシュがあると違いが生じます。その場合は、findこのケースを特別に処理してくれるはずです。)
答え2
ちなみに、find some/dir/の代わりにを使用する理由の 1 つは、 が実際にはディレクトリへのシンボリック リンクであり、find some/dirそのシンボリック リンクが指すディレクトリ内のファイルを検索する場合です。some/dirfind
しかし、その場合、より良い代替案があります。
find -H some/dir
-Hlsは、いくつかのPOSIXユーティリティ（ 、、 ...）でサポートされているオプションで、引数として渡されたシンボリックリンクcpをたどるようにユーティリティに指示します（ /chmodと混同しないでください。/は、シンボリックリンクをたどる原因になります）。-L-followfind毎シンボリックリンク、引数として渡されたものだけでなく、ディレクトリトラバーサル中に見つかったものも含まれます。
が実際にはディレクトリではないfind some/dir/場合、これは機能的に と同等ではありません。その場合、は失敗し、some/dirfind some/dir/ディレクトリではありませんfind -H some/dirディレクトリ以外のファイルをリストするときにエラーが発生しました。