Em sistemas semelhantes ao UNIX ao longo dos anos (o mais relevante para mim, o Linux), notei que . (diretório atual) nunca está no $PATH por padrão. Por que isso acontece?
Eu me lembro de ter lido anos atrás que era um problema de segurança, mas o artigo que li não explicava exatamente qual era o problema. É porque alguém poderia deixar uma versão maliciosa de ls ou cp em um diretório, e eu acabaria rodando sem perceber que estava lá?
Sim. Se você colocar o "." no caminho, você acabaria enviando muitas chamadas de comando para os arquivos em seu diretório atual.
Mesmo que tenha sido o último, ainda há erro do piloto. Por exemplo, o Solaris 10 carece de "top". Eu digito "top" no meu sistema o dia todo, porque acho que estou em um sistema que tem "top".
Desculpe, gostaria de perguntar isso na forma de um comentário à resposta selecionada, mas ainda não tenho nenhum representante no superusuário.
A resposta de segurança faz sentido, mas se você colocar "." no seu PATH como a última coisa, o shell não deve procurar no diretório atual por último, pois ele procura executáveis e, assim, reduz o risco de segurança? Se ele pesquisasse $ PATH em ordem, encontraria / bin / ls antes de encontrar ./ls.
Então, quão inseguro é para mim colocar "." no final da minha variável de ambiente $ PATH?
Funciona como eu sugiro. Veja como eu testei:
Primeiro, adicione "." ao END da variável de ambiente PATH.
Em seguida, coloque o seguinte arquivo em algum diretório, como ~ / dir1 / dir2 / test_which.rb:
#!/your/path/to/ruby
puts "this file is from the current directory"
E coloque este arquivo em /usr/bin/test_which.rb
#!/your/path/to/ruby
puts "this file is at /usr/bin/test_which.rb"
Certifique-se de chmod + x os arquivos para que eles sejam executáveis.
Agora, se você alterar o diretório para ~ / dir1 / dir2 e executar test_which.rb, você obterá a saída
this file is at /usr/bin/test_which.rb
De fato, se você rodar "which test_which.rb" de qualquer lugar, ele deve reportar
/usr/bin/test_which.rb
Você ainda pode executar o arquivo no diretório atual digitando:
./test_which.rb
Mais do que um risco de segurança, tendo '.' no PATH tornam quase impossível ter certeza de que a execução de qualquer comando atua como pretendido. Pense em executar um comando como 'zip' em um diretório enorme contendo milhares de arquivos com nomes aleatórios. A possibilidade de que um deles seja realmente chamado de 'zip' não é insignificante e levaria a um erro que é muito difícil de entender (na verdade, o arquivo deve ser executável, o que, no entanto, pode acontecer).
Em particular, isso é verdadeiro ao escrever scripts que mantêm a variável PATH do usuário. Um bom roteiro escrito deve lidar com todos os casos de canto (como nomes de arquivos com espaços ou começando com '-'). Mas é impraticável impedir que um arquivo no diretório atual seja executado em vez de um comando do sistema ...