Qué es el PATH y por qué "command not found" casi nunca es lo que parece

Publicado el 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.

Escribís "ls" y aparece la lista de archivos. ¿Cómo supo el sistema dónde está el programa "ls"?

Con el PATH: una variable de entorno que contiene una lista de carpetas separadas por dos puntos.

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

Cuando escribís un comando sin barra, el shell recorre esas carpetas en orden, de izquierda a derecha, y ejecuta el primer archivo ejecutable que coincida con ese nombre. Si no lo encuentra en ninguna, dice "command not found".

Eso es todo el mecanismo. Y de ahí salen casi todos los problemas.

El orden importa, y mucho

Si el mismo nombre existe en dos carpetas del PATH, gana la que esté antes.

Por eso las carpetas personales suelen ir primero: permite tener tu propia versión de una herramienta sin tocar la del sistema.

Y por eso también aparecen situaciones desconcertantes. Tenés dos versiones de Python instaladas, corrés "python3" y sale la que no esperabas. La respuesta está en el orden del PATH.

Dos comandos que resuelven esto en segundos:

which python3 # cuál se ejecutaría type -a python3 # todas las que existen, en orden

El segundo es el que de verdad aclara el panorama, y casi nadie lo conoce.

Los tres casos donde falla

1. En cron. Este es el más frecuente y el más frustrante.

cron ejecuta con un PATH mínimo, que suele ser sólo /usr/bin y /bin. Tu script anda perfecto cuando lo corrés a mano y falla en la tarea programada, porque el programa que usa está en /usr/local/bin y cron no mira ahí.

La solución es usar rutas completas en los scripts de cron, o definir el PATH al principio del crontab.

2. En un script con shebang.

#!/usr/bin/env python3

Esa forma busca python3 en el PATH, lo cual es bueno para la portabilidad (respeta entornos virtuales) y significa que el resultado depende del PATH de quien lo ejecute.

La alternativa, poner la ruta fija, es predecible y menos portable. Las dos opciones son válidas: lo importante es saber cuál estás usando.

3. Después de instalar algo y "no aparece".

Muchos instaladores dejan el ejecutable en una carpeta que no está en tu PATH, y te dicen que agregues una línea a tu configuración del shell. Si esa línea no se agregó, o se agregó en un archivo que no se lee en tu tipo de sesión, el comando "no existe".

Cómo agregarlo bien

En tu archivo de configuración del shell:

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

Dos detalles importantes:

• Incluí siempre $PATH al final. Si escribís sólo la carpeta nueva, borrás todo lo demás y el sistema queda casi inutilizable en esa sesión.
• Poné la carpeta nueva adelante si querés que tenga prioridad, o al final si preferís que el sistema gane.

El detalle de seguridad

Nunca pongas el directorio actual (un punto) en el PATH.

Si lo hacés, basta con que alguien deje un archivo llamado "ls" en una carpeta por la que pases para que lo ejecutes sin darte cuenta. Es un vector de ataque clásico y por eso ninguna distribución lo incluye por defecto.

Por la misma razón, para ejecutar algo del directorio actual hay que escribir ./programa: esa barra le dice al shell "esto es una ruta, no busques en el PATH".