O que é o PATH e por que "comando não encontrado" quase nunca é o que parece

Publicado em 2026-09-12 por frfrand

Una lista de carpetas separadas por dos puntos que decide qué programa se ejecuta. Cómo se busca, por qué el orden importa tanto, y los tres casos donde falla.

Você digita "ls" e aparece a lista de arquivos. Como o sistema soube onde está o programa "ls"?

Com o PATH: uma variável de ambiente que contém uma lista de pastas separadas por dois pontos.

$ echo $PATH /home/yo/.local/bin:/usr/local/bin:/usr/bin:/bin

Quando você digita um comando sem barra, o shell percorre essas pastas em ordem, da esquerda para a direita, e executa o primeiro arquivo executável que coincida com esse nome. Se não o encontrar em nenhuma, ele diz "comando não encontrado".

Isso é todo o mecanismo. E de lá saem quase todos os problemas.

A ordem importa, e muito

Se o mesmo nome existir em duas pastas do PATH, vence a que estiver antes.

É por isso que as pastas pessoais costumam vir primeiro: permite ter sua própria versão de uma ferramenta sem tocar na do sistema.

E é por isso também que aparecem situações desconcertantes. Você tem duas versões do Python instaladas, roda "python3" e sai a que você não esperava. A resposta está na ordem do PATH.

Dois comandos que resolvem isso em segundos:

which python3 # qual seria executado type -a python3 # todas as que existem, em ordem

O segundo é o que realmente esclarece o panorama, e quase ninguém o conhece.

Os três casos onde falha

1. No cron. Este é o mais frequente e o mais frustrante.

cron executa com um PATH mínimo, que geralmente é apenas /usr/bin e /bin. Seu script funciona perfeitamente quando você o executa manualmente e falha na tarefa agendada, porque o programa que ele usa está em /usr/local/bin e o cron não verifica lá.

A solução é usar caminhos completos nos scripts do cron, ou definir o PATH no início do crontab.

2. Em um script com shebang.

#!/usr/bin/env python3

Essa forma procura o python3 no PATH, o que é bom para portabilidade (respeita ambientes virtuais) e significa que o resultado depende do PATH de quem o executa.

A alternativa, colocar o caminho fixo, é previsível e menos portátil. As duas opções são válidas: o importante é saber qual você está usando.

3. Depois de instalar algo e "não aparecer".

Muitos instaladores deixam o executável em um diretório que não está no seu PATH e dizem que você deve adicionar uma linha à configuração do shell. Se essa linha não foi adicionada, ou foi adicionada em um arquivo que não é lido no seu tipo de sessão, o comando "não existe".

Como adicioná-lo corretamente

No seu arquivo de configuração do shell:

export PATH="$HOME/.local/bin:$PATH"

Dois detalhes importantes:

• Inclua sempre $PATH no final. Se você escrever apenas o novo diretório, apagará tudo o mais e o sistema ficará quase inutilizável nessa sessão.
• Coloque o novo diretório na frente se quiser que ele tenha prioridade, ou no final se preferir que o sistema tenha precedência.

O detalhe de segurança

Nunca coloque o diretório atual (um ponto) no PATH.

Se você fizer isso, basta que alguém deixe um arquivo chamado "ls" em uma pasta por onde você passe para que ele seja executado sem que você perceba. É um vetor de ataque clássico e, por isso, nenhuma distribuição o inclui por padrão.

Por esse mesmo motivo, para executar algo do diretório atual, é preciso escrever ./programa: essa barra diz ao shell "isto é um caminho, não procure no PATH".