O $ HOME / bin,. e ./bin são geralmente vistos como um risco de segurança.
para o $ HOME / bin é o problema de alguns "crackers" empurrar algum script (digamos um script chamado nano) para lá e esperar até você executar algo como sudo nano / etc / hosts para obter acesso root instantâneo (mudar o nano para vi, emacs, seja qual for, o comando não é importante, é a carga útil que ele pode executar)
para. e ./bin ainda é o mesmo problema, acrescentou um extra: trabalhando no diretório errado.
Se esses ./bin/command estão em diretórios diferentes em vez de / usr / local / bin (a solução preferida para novos scripts locais), é porque eles fazem coisas diferentes ... e se você executar o incorreto?
Se você nomear seus comandos da mesma maneira (permite chamar, atualizar, confirmar, limpar, etc), você pode estar trabalhando em um diretório, então você recebe um telefonema e muda para outro para uma verificação rápida. Depois de desligar, seu cérebro tentará retomar o que você estava fazendo e, na maioria das vezes, esquecerá o rápido "cd" que você fez (especialmente se tudo na tela parecer apontar para o diretório correto) e terminará de executar um comando errado. diretório (digamos que o script de limpeza apaga todo o seu trabalho mensal).
Pode parecer um erro inocente, mas acontece todos os dias para muitas pessoas! :)
uma boa solução alternativa (ou melhor solução) é usar o alias:
alias proj1-cleanup=/srv/proj1/bin/cleanup
e adicione no script o cd correto para garantir que ele seja executado no diretório correto.
Desta forma, jogue com o $ HOME / .alias para adicionar os vários scripts que você precisa, você tem comandos diferentes para fazer as coisas diferentes, e até mesmo se alguém crackear seu navegador para criar um arquivo $ HOME / bin / ls ou algum o usuário local cria um arquivo bin / ls em qualquer diretório, esses nunca serão executados, pois seu caminho ainda aponta para os comandos corretos.
mas ei, é uma escolha pessoal, você é quem sabe quais são seus riscos locais e o que os comandos fazem.