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:
/usr/local/sbin/usr/local/bin/usr/bin
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:
- Abra o arquivo de perfil:
vi /root/.bashrc
- Entre no modo de edição apertando
i, adicione a linha de exportação no final e salve comEsc+:wq.
- Recarregue as variáveis na sessão atual:
source /root/.bashrc
- 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:
Opção a: criar um link simbólico (mais recomendado)#
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:
Este post está licenciado sob CC BY-NC.



Comentários
Participe da discussão abaixo.
0 comentários