Это ошибка, что когда я find ./path/here/получаю:
./path/here//foo
./path/here//bar
Я знаю, findчто хочет, чтобы я указал путь без завершающего слеша, но наверняка он может обнаружить путь, который оставляет мне автодополнение табуляции, и соответствующим образом скорректировать свой вывод. Есть ли какая-то причина, по которой он этого не делает?
решение1
Технически, это ошибка, потому чтоСостояния POSIXчто
все имена путей для других файлов, встречающихся в иерархии, должны состоять из конкатенации текущего операнда пути, <слэша>если текущий операнд пути не закончился на один, и имя файла относительно операнда пути
Нодвойной слеш не имеет никакого значения, so ./path/here//fooи ./path/here/fooвсегда являются одним и тем же файлом. (Двойной слеш имеет значение, если он находится в начале пути в некоторых вариантах Unix. Если у вас он есть, то, надеюсь, findэтот случай будет рассмотрен специально.)
решение2
Для справки, одна из причин, по которой можно использовать find some/dir/вместо , find some/dirзаключается в том, что на some/dirсамом деле это символическая ссылка на каталог, и вы хотите findнайти файлы в каталоге, на который указывает эта символическая ссылка.
Но в таком случае есть лучшая альтернатива:
find -H some/dir
-H— это опция, поддерживаемая несколькими утилитами POSIX ( ls, cp, chmod...), которая сообщает утилите, что нужно следовать символическим ссылкам, переданным в качестве аргументов (и только им, не путать с -L/ -follow, что заставляет findследоватькаждыйсимволические ссылки, переданные в качестве аргументов, а также найденные во время обхода каталога).
Это все еще не функционально эквивалентно find some/dir/в случае, когда some/dirна самом деле не является каталогом. В этом случае find some/dir/произойдет сбой сНе каталогошибка, в то время как find -H some/dirбудет выведен этот файл, не являющийся каталогом.