Existe alguma diferença w / v / s sem “./” em um caminho relativo?

Question

Existe alguma diferença sutil entre:

file

e

./file

como um caminho relativo?

    

Answer 1

Quando usado como um nome de comando em um shell ou nas funções exec*p() libc, file procuraria file em $PATH (ou em um shell, possivelmente invocaria a versão incorporada ou funcionar com esse nome), enquanto ./file executaria o diretório atual.

Não é que ./ acione um comportamento especial, mas se o nome do comando não contiver / , ele fará uma pesquisa $PATH . ./cmd é a maneira mais óbvia de fornecer um caminho para cmd que contém / .

O prefixo ./ também é comumente usado para garantir que um nome de arquivo não comece com um caractere problemático para alguns comandos.

Por exemplo:

rm ./-f

remove -f , enquanto rm -f chamaria rm com a opção -f ( rm -- -f também funcionaria). Ou:

cat ./-
awk '{print $1}' ./a==b.txt

onde -- não ajudaria.

Você acha isso como rm ./* ou awk ... ./* em scripts nos quais você não sabe se a expansão de * produziria caracteres problemáticos.

    

Answer 2

Sim. Vários.

Funções da biblioteca C

Como mencionado em outra resposta, a família exec*p() das funções de biblioteca usa se o nome contém um caractere de barra como um teste para determinar se a pesquisa de caminho deve ser executada.

Leitura adicional

• O que é "Todos os shells e programas que usam chamadas da biblioteca exec * p lidam com a pesquisa"?

Outras coisas que pesquisam caminhos

Os programas podem, claro, fazer suas próprias pesquisas de caminho com a biblioteca C. Eles podem estar procurando por outras coisas além de executá-las. Ou eles podem querer um comportamento ligeiramente diferente daquele das funções da biblioteca C, que tem algumas surpresas pouco conhecidas para aqueles que não estão cientes do que o padrão POSIX exige. Então eles implementam seu próprio código de busca. Geralmente, eles seguirão as convenções da biblioteca C e, se o nome contiver um caractere de barra, apenas usarão o nome como está.

Por exemplo:

Os shells que possuem mecanismos CDPATH ou cdpath executam esse tipo de pesquisa e têm esse comportamento. Aqui está o shell TENEX C:

~> set cdpath=(/usr /)
~> cd ./etc
./etc: No such file or directory.
~> cd etc
/etc
/etc> 

Nomes de arquivo que começam com um sinal de menos

Uma das maneiras de garantir que um nome de arquivo que comece com um sinal de menos não seja considerado uma opção de linha de comando é prefixar com ./ . Por exemplo:

• rm ./-rf é um nome de arquivo e rm -rf é uma opção de linha de comando.
• find ./-name wibble está varrendo duas árvores de diretórios e encontrando tudo; Considerando que find -name wibble está varrendo uma árvore de diretórios e aplicando uma correspondência de padrões.

Leitura adicional

• Como faço para excluir um arquivo cujo nome começa com "-" (hífen aka traço ou subtração)?

Comandos onde a sintaxe do comando torna isso importante

Às vezes, a sintaxe do comando é definida de tal forma que algo é apenas um nome de arquivo se começar com um ponto final. Caso contrário, é outra coisa. De certa forma, isso é uma generalização do sinal de menos como uma convenção de caracteres de opção.

Por exemplo:

Com multilog de Dan Bernstein, de daemontools, Bruce Guenter's multilog do daemontools-encore, o djbwares multilog , e s6-log de Laurent Bercot do s6, o comando Os argumentos de linha são um script de log onde a primeira letra de cada argumento indica que tipo de comando de script é. Para denotar um diretório de log, é necessário fornecer um argumento de cadeia de comando que comece com uma barra ou um caractere de parada completa. multilog ./t ./u significa log para dois diretórios; Considerando que multilog t ./u significa logar em um diretório e preceder data e hora.

    

Answer 3

file pesquisará no seu PATH do arquivo.

./file ignorará o PATH e pesquisará no diretório atual.