ti-enxame.com

Por que usamos "./" (barra) para executar um arquivo no Linux / UNIX?

Por que usamos ./filename para executar um arquivo no linux?

Por que não inseri-lo como outros comandos gcc, ls etc ...

89
Renjith G

No Linux, UNIX e sistemas operacionais relacionados, . indica o diretório atual. Como você deseja executar um arquivo no diretório atual e esse diretório não está no seu $PATH, você precisa do ./ bit para informar ao Shell onde está o executável. Assim, ./foo significa executar o executável chamado foo que está neste diretório.

Você pode usar type ou which para obter o caminho completo de qualquer comando encontrado em seu $PATH.

80
badp

A resposta literal é a que outros deram: porque o diretório atual não está no seu $PATH.

Mas por quê? Em resumo, é por segurança. Se você estiver procurando no diretório pessoal de outra pessoa (ou/tmp) e digitando apenas gcc ou ls, deseja saber que está executando o diretório real, não uma versão maliciosa amigo brincalhão escreveu que apaga todos os seus arquivos. Outro exemplo seria test ou [, que pode substituir esses comandos nos scripts do Shell, se o seu Shell não os tiver como internos.

Tendo . como a entrada last no seu caminho é um pouco mais segura, mas existem outros ataques que fazem uso disso. Uma solução fácil é explorar erros de digitação comuns, como sl ou ls-l. Ou encontre um comando comum que não esteja instalado neste sistema - vim, por exemplo, pois os administradores de sistemas têm probabilidade acima da média de digitar isso.

103
mattdm

Se você quer dizer, por que você precisa de ./ no início - é porque (diferente do Windows), o diretório atual não faz parte do seu caminho por padrão. Se você executar:

$ ls

seu Shell procura ls nos diretórios em sua variável de ambiente PATH (echo $PATH para vê-lo) e executa o primeiro executável chamado ls encontrado. Se você digitar:

$ a.out

o Shell fará o mesmo - mas provavelmente não encontrará um executável chamado a.out. Você precisa informar ao Shell onde está o a.out - ele está no diretório atual (.) E o caminho é ./a.out.

Se você está perguntando por que é chamado "a.out", esse é apenas o nome do arquivo de saída padrão para o gcc. Você pode alterá-lo com a linha de comando -o arg. Por exemplo:

$ gcc test.c -o test
$ ./test
45
Simon Whitaker

Você pode tentar adicionar :. para sua variável $ PATH.

Tente ALT + F2 e digite: gksudo gedit /etc/environment se estiver executando o Linux/GTK (é o que você tem se estiver usando o Ubuntu).

No entanto, eu recomendo fortemente que você não faça isso. É ruim, ruim, ruim e ruim.

Você sabe, esse tipo de coisa funciona assim desde 1970. Há uma razão pela qual o diretório atual não está incluído no $ PATH.

. é o diretório atual

.something seria um arquivo oculto (digite "ALT +" para fazê-los aparecer no Nautilus ou tente "ls -la ".

./someProgram.sh é o que você digita para EXECUTAR um executável someProgram.sh no diretório atual.

.somethingElse significaria que você tem um executável oculto no diretório atual, o que é uma má idéia.

4
tiktak

A regra mais completa é realmente: se houver uma barra / No caminho, não procure PATH

Antes de entrarmos na lógica, você deve primeiro saber sobre esse fato: executando um dos seguintes:

bin/someprog

ou:

/bin/someprog

ou:

cd bin
./myexec

execute bin/someprog sem pesquisar a variável PATH pelo mesmo motivo: todos os bin/someprog, /bin/someprog e ./someprog possuem uma barra / Neles.

someprog sozinho não possui uma barra / e, portanto, procura apenas em PATH.

POSIX 7 especifica esta regra em: http: //pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

Justificativa para a regra POSIX PATH /

Suponha que executando:

someprog

pesquisaria:

  • em relação à CWD primeiro
  • em relação ao PATH após

Então, se você deseja executar /bin/someprog Da sua distribuição, e você fez:

someprog

algumas vezes funcionava, mas outras falhava, porque você pode estar em um diretório que contém outro programa someprog não relacionado.

Portanto, você logo aprenderia que isso não é confiável e acabaria sempre usando caminhos absolutos quando desejar usar o PATH, derrotando, portanto, o objetivo do PATH.

É também por isso que ter caminhos relativos no PATH é uma péssima ideia. Estou olhando para você, node_modules/bin .

Por outro lado, suponha que a execução:

./someprog

Pesquisaria:

  • em relação ao PATH primeiro
  • em relação à DRC após

Então, se você apenas baixou um script someprog de um repositório git e quisesse executá-lo no CWD, nunca teria certeza de que este é o programa que seria executado, porque talvez sua distribuição possua:

/bin/someprog

que está no seu PATH de algum pacote que você instalou depois de beber demais depois do Natal do ano passado.

Portanto, mais uma vez, você seria forçado a sempre executar scripts locais relativos ao CWD com caminhos completos para saber o que está executando:

"$(pwd)/someprog"

o que seria extremamente irritante também.

Outra regra que você pode ser tentado a criar seria:

caminhos relativos usam apenas PATH, caminhos absolutos apenas CWD

mas, mais uma vez, isso força os usuários a sempre usar caminhos absolutos para scripts não PATH com "$(pwd)/someprog".

A regra de pesquisa de caminho / Oferece uma solução simples de lembrar para o problema sobre:

  • barra: não use PATH
  • sem barra: use apenas PATH

o que torna super fácil saber sempre o que você está executando, confiando no fato de que os arquivos no diretório atual podem ser expressos como ./somefile ou somefile e, portanto, confere um significado especial a um deles.

Às vezes, é um pouco chato que você não possa procurar por some/prog Em relação a PATH, mas não vejo uma solução mais adequada para isso.