Troubleshooting no Linux: o dia em que o 'command not found' me fez revisar o $PATH e o sudo su
Voltar para blog

Troubleshooting no Linux: o dia em que o 'command not found' me fez revisar o $PATH e o sudo su

13/09/2026 · 4 min · Infraestrutura

Quem mexe com terminal Linux no dia a dia com certeza já passou por isso: você tenta rodar um binário no sistema, recebe um aviso de comando não encontrado, ajusta as variáveis de ambiente, recarrega o shell e… o erro continua lá, como se você não tivesse feito nada.

Recentemente passei por esse clássico problema de ambiente tentando rodar um executável chamado mimo como root. O processo de isolar a falha serviu para consolidar pontos fundamentais sobre como o Bash carrega perfis, a sintaxe da variável $PATH, as armadilhas do comando su e a estratégia correta para encontrar arquivos no disco.


O ponto de partida e o erro teimoso#

O objetivo inicial era garantir que os diretórios padrão do sistema estivessem presentes no $PATH da conta root:

Ao tentar verificar se o binário mimo existia com o comando which (ou com o padrão portátil POSIX command -v mimo), o terminal acusou ausência:

[root@hackerpc /]# which mimo
which: no mimo in (/usr/local/sbin:/usr/local/bin:/usr/bin)

Mesmo editando o /root/.bashrc e forçando a leitura com o comando source, a resposta continuava a mesma:

[root@hackerpc /]# mimo
bash: mimo: comando não encontrado

[root@hackerpc /]# source /root/.bashrc
[root@hackerpc /]# mimo
bash: mimo: comando não encontrado

Havia claramente uma divergência entre o que eu achava que estava acontecendo na sessão e o estado real do terminal.


Onde as coisas costumam falhar: os 3 pontos críticos#

Analisando o que estava acontecendo, isolei três causas comuns que provocam esse comportamento:

1. A armadilha do sudo su sem o traço de login (-)#

Mudar para o usuário root rodando apenas sudo su mantém parte do ambiente e variáveis herdadas do seu usuário comum anterior. O Bash não cria uma sessão de login limpa do root, o que impede o carregamento completo de arquivos como /root/.bash_profile ou /root/.bashrc.

O jeito certo: Usar sudo su - (ou sudo -i). O traço no final força o shell a abrir como uma sessão de login nova, limpando o ambiente antigo e lendo os dotfiles nativos do /root.

2. Edição incorreta no editor vi#

Durante ajustes rápidos no /root/.bashrc, apertar Ctrl + C dentro do vi cancela o modo de inserção sem gravar nada no disco. Para salvar de verdade, você precisa apertar Esc para voltar ao modo de comando e digitar :wq seguido de Enter.

3. A precedência e a sintaxe correta do $PATH#

Para garantir que os diretórios do sistema tenham prioridade sem perder os caminhos já existentes, a declaração de exportação deve ser:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:$PATH

Dica de segurança: Colocar os diretórios confiáveis do sistema antes do $PATH herdado protege a conta root contra a execução acidental de scripts indesejados presentes em pastas secundárias.


Aplicando a correção na variável#

Para padronizar o perfil do root:

  1. Abra o arquivo de perfil:
vi /root/.bashrc
  1. Entre no modo de edição apertando i, adicione a linha de exportação no final e salve com Esc + :wq.
  1. Recarregue as variáveis na sessão atual:
source /root/.bashrc
  1. Verifique o resultado com:
echo $PATH

O diagnóstico definitivo: onde o arquivo realmente está?#

Após corrigir o $PATH e abrir a sessão com sudo su -, a mensagem de erro mudou para o padrão do shell (-bash: mimo: command not found). Isso confirmou que o ambiente estava carregando direito, mas o arquivo mimo simplesmente não existia em nenhuma daquelas pastas.

Quando o $PATH está certo e o comando ainda não roda, o problema deixa de ser configuração de shell e passa a ser a localização física do arquivo no disco.

Para varrer o sistema inteiro procurando pelo executável sem poluir a tela com erros de pastas sem permissão:

find / -name "mimo" 2>/dev/null

O que fazer depois de encontrar o binário#

Assim que o find retornar o caminho completo onde o arquivo está guardado, você tem duas opções práticas:

Se o programa estiver instalado em uma pasta como /opt/mimo ou na home de outro usuário, crie um atalho dentro de uma pasta já monitorada pelo $PATH:

ln -s /caminho/encontrado/mimo /usr/local/bin/mimo

Opção b: ajustar as permissões de execução#

Se o arquivo já estiver em uma pasta correta mas ainda recusar a execução, garanta que ele tem permissão de executável com:

chmod +x /caminho/encontrado/mimo

Conclusão#

Investigar falhas de comando no Linux segue uma ordem lógica bem clara: primeiro confere-se como a sessão foi iniciada (sudo su -), depois valida-se a persistência no /root/.bashrc, em seguida a ordem do $PATH, e por fim a localização real do arquivo no disco com suas permissões.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

CC BY-NC

Este post está licenciado sob CC BY-NC.

Comentários

Participe da discussão abaixo.

0 comentários