Além de razões de segurança (como Anders tem referido ), mantendo o PATH
do usuário original em conformidade com o Princípio de menor espanto .
Suponha que você execute um programa chamado foo
, mas descubra que realmente precisa executá-lo como root
. Então você corre sudo foo
. Seria ruim se o programa executado por sudo foo
fosse diferente do programa executado por foo
, o que aconteceria se houvesse um% diferentefoo
em root
PATH
. Isso basicamente violaria suas expectativas e a suposição geral de que sudo
faz a mesma coisa que você coloca depois, exceto como root
.
Isso é o que aconteceria se sudo
pré pagasse root
PATH
ao seu PATH
. Mas suponha que sudo
ap pagou o caminho de root
para o seu PATH
. Se esse era o comportamento de sudo
, provavelmente você presumiria que, se pudesse executar um programa (chame-o de bar
) ao simular um shell de login root
inicial ( sudo -i
), também poderia executá-lo com sudo bar
. Mas essa suposição estaria errada, porque pode haver um bar
diferente em seu próprio caminho (ou seja, não root
).
Em vez do comportamento de sudo
mudar de um lançamento do Ubuntu para outro, o que provavelmente aconteceu foi que seu PATH
mudou. Se você adicionar /sbin
, /usr/sbin
e /usr/local/sbin
ao seu PATH
, o problema será resolvido. A menos que você queira apenas sbin
em seu PATH ao executar programas como root
. Nesse caso, eu recomendo postar uma pergunta separada sobre isso (embora uma técnica para realizar isso seja sugerida na resposta de Anders . )