É um bug que, quando recebo find ./path/here/:
./path/here//foo
./path/here//bar
Eu sei findque quer que eu especifique o caminho sem a barra final, mas certamente ele pode detectar o caminho que o preenchimento da guia me deixa e ajustar sua saída de acordo. Existe alguma razão pela qual isso não acontece?
Responder1
Tecnicamente, é um bug, porqueEstados POSIXque
todos os nomes de caminho para outros arquivos encontrados na hierarquia devem consistir na concatenação do operando do caminho atual, uma <barra>se o operando do caminho atual não terminasse em ume o nome do arquivo relativo ao operando do caminho
Masa barra dupla não faz diferença, então ./path/here//fooe ./path/here/foosão sempre o mesmo arquivo. (Uma barra dupla faz diferença se estiver no início do caminho em algumas variantes do Unix. Se a sua fizer isso, esperamos que findtrate esse caso de maneira especial.)
Responder2
Para constar, um motivo pelo qual alguém pode usar find some/dir/em vez de find some/diré quando some/diré na verdade um link simbólico para um diretório e você deseja findencontrar arquivos no diretório apontado por esse link simbólico.
Mas, nesse caso, há uma alternativa melhor:
find -H some/dir
-Hé uma opção suportada por alguns utilitários POSIX ( ls, cp, chmod...) que diz ao utilitário para seguir links simbólicos passados como argumentos (e apenas esses, não devem ser confundidos com -L/ -followque faz com que findsigamtodolink simbólico, aqueles passados como argumentos, mas também aqueles encontrados durante a passagem do diretório).
Isso ainda não é funcionalmente equivalente ao find some/dir/caso em que some/dirna verdade não é um diretório. Nesse caso, find some/dir/falharia com umNão é um diretórioerro ao find -H some/dirlistar esse arquivo que não é de diretório.