Em sistemas semelhantes ao UNIX ao longo dos anos (o mais relevante para mim, Linux), notei que .(dir atual) nunca está no $PATHpadrão. Por que é isso?
Lembro-me de ler 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 lsou cpem um diretório e eu acabaria executando-a sem perceber que ela estava lá?
Respostas:
Você respondeu corretamente sua própria pergunta, é exatamente por isso que o ponto não está no caminho:
para se proteger contra vírus infantis ou erros honestos.
Obviamente, essa é uma medida antivírus muito inútil e inútil, e nada impede você de adicionar um ponto ao caminho.
-rfno diretório (torna rm *interessante) ;-)
-rfem primeiro lugar? ;)
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 existe um erro piloto. Por exemplo, o Solaris 10 não possui "top". Eu digito "top" no meu sistema o dia todo, porque acho que estou em um sistema que tem "top".
Desculpe, gostaria de fazer isso na forma de um comentário para a resposta selecionada, mas ainda não tenho nenhum representante no superusuário.
A resposta de segurança faz sentido, mas se você colocar "." no PATH como a última coisa, o shell não deve procurar no diretório atual por último enquanto procura por executáveis e, assim, reduzir 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. Aqui está como eu testei:
Primeiro, adicione "." até o final da sua 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 dos arquivos para que sejam executáveis.
Agora, se você alterar o diretório para ~ / dir1 / dir2 e executar test_which.rb, obterá a saída
this file is at /usr/bin/test_which.rbDe fato, se você executar "what test_which.rb" de qualquer lugar, ele deverá reportar
/usr/bin/test_which.rbVocê ainda pode executar o arquivo no diretório atual digitando:
./test_which.rbdcou slou sduoem um shell, e foi salvo por "comando não encontrado". Sempre.
ls(saída colorida e muito mais) com alias à lqual dispensa inteiramente erros de digitação.
Mais do que um risco de segurança, ter '.' no PATH torna quase impossível garantir que a execução de qualquer comando atue 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 um deles ser realmente chamado de 'zip' não é desprezível 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 é verdade ao escrever scripts que mantêm a variável PATH do usuário. Um bom script escrito deve lidar com todos os casos de canto (como nomes de arquivos com espaços neles ou começando com '-'). Mas é impraticável impedir que um arquivo no diretório atual seja executado em vez de um comando do sistema ...
lsserá/usr/bin/lsou./lsnão. Há também o obstáculo de que, se você souber como adicionar.um final ao seu caminho, provavelmente terá alguma ideia do que está fazendo. O root nunca deve estar.no caminho, muitos sistemas nem deixam mais o logon raiz.