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 . )