¿Para que sirve el comando Which en Linux? Todo explicado​

Te llevamos por los entresijos del comando Which en Linux, mostrando cómo ubicar ejecutables y evitar errores con ritmo y claridad técnica.

En cualquier sistema Unix o Linux, escribir un comando y pulsar Intro pone en marcha una coreografía silenciosa: la shell recorre una lista de directorios definida en la variable $PATH, decide qué ejecutable lanzar, resuelve enlaces simbólicos, respeta prioridades y, si hay alias o funciones con el mismo nombre, se impone su lógica interna. En medio de esa danza, which actúa como un pequeño foco: apunta a qué binario se ejecutará cuando escribes un nombre. Nada más… y, al mismo tiempo, mucho más. Quien ha pasado una tarde persiguiendo un bug que se debía a que estaba llamando al ejecutable equivocado sabe que contar con esta certeza vale oro.

La pregunta que subyace —¿dónde está exactamente el programa que estoy usando?— parece trivial. No lo es. Entre entornos virtuales, contenedores, gestores de versiones de lenguajes, alias de la shell, rutas duplicadas o usuarios que cambian de sudo a sesión normal sin fijarse, la respuesta se complica. Ahí, which es directo: imprime la ruta del ejecutable que la shell buscaría en tu contexto actual. Y con eso, empiezas a entender qué está pasando en tu máquina.

Conviene decirlo desde ya, con naturalidad y sin rodeos: para qué sirve el comando which en linux se resume en dos verbos, localizar y verificar. Localiza el binario que se ejecutará y verifica que coincide con lo que pensabas. Con ese gesto, evitas caminos equivocados, ejecutables “fantasma” y errores que, a veces, parecen magia.

Qué es y para qué sirve which en Linux

which es una utilidad de usuario que consulta tu $PATH y, para cada nombre que recibe, devuelve la primera ruta coincidente con un ejecutable. Si no encuentra nada, lo dice y su código de salida es distinto de cero. No es parte del estándar POSIX, aunque está presente en prácticamente todas las distribuciones. En pocas palabras: te dice qué se va a ejecutar cuando llamas a un comando desde tu terminal.

Su utilidad es inmediata. Te permite confirmar si el python que invocas pertenece al virtualenv del proyecto o al del sistema; comprobar si node proviene de nvm o de un paquete del sistema; saber si ffmpeg lo instalaste via snap, Flatpak o gestor de paquetes nativo; o descubrir por qué al usar sudo se ejecuta otra versión distinta. También sirve para documentar entornos: cuando alguien te pregunta “¿qué git tienes?”, responder con la ruta y no solo con la versión ahorra malentendidos.

Bajo el capó: cómo decide which

La lógica es clara: la shell recorre $PATH de izquierda a derecha. Ese orden es prioridad. Si en el primer directorio aparece un archivo ejecutable con el nombre solicitado, ahí termina la búsqueda. which simula esa misma estrategia y te muestra el primer acierto. Si le pides más transparencia, puedes pedir todas las coincidencias para ver el “stack” completo de alternativas.

Cuando entiendes el orden de $PATH, entiendes por qué una utilidad que instalaste en tu $HOME/bin (o en ~/.local/bin) se impone sobre la del sistema, o por qué un contenedor con su propia ruta preferida te cambia el binario sin avisar. which hace visible esa prioridad.

Sintaxis y opciones que de verdad importan

La forma más habitual de uso es directa:

A menudo, conviene ver todas las rutas posibles que coinciden con un nombre para detectar sombras en el PATH:

Esa salida revela si tienes duplicidades —por ejemplo, una versión en /usr/bin y otra en /usr/local/bin— y te permite decidir cuál debe ir antes en tu PATH.

Hay implementaciones que reconocen opciones para saltar directorios poco recomendables en entornos de producción, como . o ~ cuando aparecen en el PATH. Son atajos útiles de higiene operativa. Si no las tienes, el remedio es el mismo: reordenar $PATH para que lo “limpio” vaya primero.

Casos reales de uso, con trampa y sin ella

Cuando trabajas con entornos Python, se vuelve crítico:

Esa doble salida de pip te avisa: mejor invocar el pip del entorno virtual para evitar instalar paquetes en el sistema por error. Otro clásico:

Sabrás que nvm manda, y no la versión del sistema. O este otro, tras instalar una herramienta en ~/.local/bin:

Si en cambio ves /usr/bin/mytool, sabrás que no estás llamando a la versión que creías. Y tomarás medidas.

Limitaciones y malentendidos recurrentes

which tiene un límite importante: no sabe nada de alias, funciones de la shell o builtins. Si en Bash has definido alias ls='ls --color=auto', which ls no te desvelará el alias; te devolverá el binario base. Si escribes una función kubectl() que prepara variables y luego llama al ejecutable, which kubectl apuntará al binario, no a tu función. Y si el comando es un builtin de la shell (cd, echo, test), which no puede mostrar una ruta porque no hay binario.

Para estas situaciones, conviene usar herramientas de introspección de la shell:

type
Muestra qué es un nombre: alias, función, builtin o fichero, e incluso todas las ubicaciones si añades -a.

command -v
Muy popular en scripts por ser portátil. Si existe, devuelve el camino o el tipo de objeto; su código de salida (0/1) permite comprobar dependencia sin imprimir nada:

Dicho de otro modo: which brilla en sesiones interactivas cuando quieres ver rutas y prioridades; command -v y type son preferibles en automación y chequeos programáticos. Saber distinguirlos te evita tortazos.

Bash, Zsh y compañía: pequeños matices que importan

En Bash, which suele ser un ejecutable externo y type es un builtin muy fiable. En Zsh, muchos usuarios utilizan whence o el propio which integrado, que se comporta de forma ligeramente distinta y entiende mejor alias y funciones. También existen caches de búsqueda: Bash mantiene una tabla de hash con resoluciones de comandos para ir más rápido. Si instalas una herramienta nueva y la ruta ha cambiado, quizá necesites vaciar esa caché:

¿Te suena ese “¿por qué sigue cogiendo la ruta vieja?” tras mover un binario? Era esto.

Scripts y portabilidad: elegante y sin sorpresas

Cuando la prioridad es que tu script funcione igual en diferentes máquinas, el patrón robusto es:

Puedes usar type -P en Bash para obtener solo la ruta del ejecutable, pero no todas las shells lo implementan igual. which, aunque omnipresente, no es estándar y cambia sutilmente entre distribuciones. Resumen práctico: en scripts, mejor command -v; en tu día a día de terminal, which te da la foto rápida que necesitas.

Buenas prácticas y pequeños sustos que evita

La limpieza del $PATH es seguridad y claridad. Si aparece el directorio actual (.) al principio, abres la puerta a ejecuciones no deseadas: un binario malicioso con el mismo nombre que un comando habitual se ejecutaría antes que el del sistema. which te ayudará a detectarlo al mostrar que el primer acierto cae en .. Quita ese punto o envíalo al final, y listo.

Otra escena frecuente: cambias de usuario con sudo y, de repente, estás ejecutando otro env distinto. sudo puede ajustar el PATH según su configuración. No es raro que which python como usuario normal y sudo which python apunten a rutas distintas. No hay misterio: son entornos diferentes. Verifica siempre con which -a y, si necesitas el mismo PATH bajo sudo, revisa la política o úsalo con cuidado (por ejemplo, sudo -E en entornos donde esté permitido y tenga sentido, sabiendo lo que haces).

También hay casos en que te interesa la ruta real, no el enlace simbólico. Puedes encadenar herramientas:

Con eso resuelves la ruta final tras seguir los enlaces. Útil cuando trabajas con gestores que colocan shims —nvm, pyenv, rbenv— para redirigir a la versión activa.

Entornos modernos: contenedores, virtualización y gestores de versiones

Trabajar en Docker o Podman trae otra capa: la imagen define su propio $PATH. Si el contenedor añade /usr/local/sbin por delante, tu which dentro del contenedor contará otra historia que la de tu host. Documentarlo con rutas explícitas te evita confundir entornos.

Con virtualenv y conda, which python o which pip confirman de un vistazo si activaste el entorno correcto. Con pyenv, which te mostrará un shim que delega en la versión seleccionada —de ahí la utilidad de readlink -f si quieres llegar al binario final. Lo mismo con rbenv en Ruby, asdf en multi-lenguajes o goenv para Go.

En editores y IDEs que lanzan terminales integrados, el $PATH puede heredarse distinto al de tu shell de login. ¿Te ejecuta otra node dentro de VS Code que en tu terminal del sistema? which en ambas consolas te lo dirá sin dramas.

Solución de problemas: cuando which parece mentir

A veces, which y la realidad no cuadran. Tres causas típicas:

La tabla de hash de la shell está desactualizada. Vacíala (hash -r o rehash) y repite.

Has editado $PATH, pero en otra sesión que no aplica a la actual. Cierra y abre terminal, o exporta correctamente.

El nombre no es un ejecutable, sino un alias o función. Prueba con type -a.

Un detalle más: en sistemas con múltiples gestores de paquetes (nativo, snap, Flatpak, Homebrew en Linux), el orden en el PATH decide. which -a es la linterna que saca a la luz qué se ejecuta antes. Saberlo te ahorra reinstalar sin necesidad.

Alternativas que completan el cuadro

type te dice si un nombre es alias, función, builtin o fichero, y con -a lista todas las coincidencias. Ideal para distinguir qué está resolviendo la shell.

command -v es portátil y silencioso; perfecto para scripts y chequeos de dependencia. Permite ramificar lógica según exista o no un comando, sin imprimir nada por pantalla.

whereis busca en ubicaciones predefinidas y te devuelve binarios, fuentes y páginas man relacionadas. Útil cuando rastreas instalación y documentación, pero menos preciso para saber “qué se ejecutará exactamente ahora”.

whence en Zsh (o el which integrado de esa shell) entiende mejor alias y funciones. Si usas Zsh, vale la pena adoptarlo para introspección interactiva.

En resumen: which te resuelve la foto rápida del ejecutable; type te explica qué es ese nombre; command -v te da la condición programable; whereis complementa con contexto.

Consejos operativos que funcionan a diario

Piensa en $PATH como una prioridad editable. Si quieres que prevalezcan tus herramientas de usuario, pon ~/.local/bin o ~/bin antes que /usr/bin. Si prefieres las del sistema, invierte el orden. Y documenta ese criterio en tu .bashrc o .zshrc con un comentario claro.

Usa negritas mentales —esas cosas que no se olvidan:

Comprueba con which antes de ejecutar algo delicado. Evitas tocar el binario equivocado.

Después de instalar o mover un ejecutable, “rehash”. No des por hecho que la shell lo pilló.

En scripts, command -v es tu amigo. Evitas una dependencia faltante con mensajes claros.

Desconfía de . al principio del PATH. Es una puerta desnecesaria para sobresaltos.

Si sudo te cambia el PATH, no es capricho. Son políticas. Mira qué which te devuelve como root y actúa en consecuencia.

No hace falta convertirlo en ritual, pero sí en reflejo. Dos o tres veces al día, which te puede ahorrar un hilo en el issue tracker.

Un vistazo más allá de la ruta: versiones, enlaces y realidad

Cuando investigas un problema, la ruta es el comienzo, no el final. Conviene mirar la versión:

Y, si sospechas de enlaces simbólicos:

Ese doble paso —saber qué ejecutas y desde dónde— es el núcleo de muchos diagnósticos. Verás que lo aplicas casi sin pensar: confirmas la ruta con which, validas la versión, cruzas con la configuración del proyecto y decides.

Una nota de estilo para desarrolladores de equipo

Cuando documentes pasos de instalación o onboarding, incluye rutas concretas junto a versiones. No escribas solo “ten node 20”; añade “la ruta que which node devuelve debe caer en ~/.nvm/versions/...”. Esa precisión previene días de confusión a quienes llegan con otro setup. Y cuando cierres una incidencia por “no reproducible”, adjunta tu which y tu PATH. Es cortesía y prueba.

Un uso sutil: auditar el PATH con -a

Ver todas las rutas que pueden resolver un nombre te ayuda a limpiar:

Si aparecen entradas antiguas en /snap/bin que ya no usas, o versiones en /usr/local/bin que quedaron de una instalación manual, es buen momento para podar. Ajusta PATH y, si hace falta, desinstala. Menos es más.

Lo esencial, sin adorno innecesario

La clave, repetida con intención para quien busca claridad: para qué sirve el comando which en linux es para saber qué binario ejecutas y dónde está. Nada de adivinanzas. Con esa información delante, disparas menos a ciegas, entiendes por qué un entorno responde como responde, y tomas decisiones con criterio.

Un apunte sobre errores y códigos de salida

which devuelve 0 si encontró todos los nombres que le pasaste, y no cero si alguno faltó. Esto permite construcciones rápidas en la terminal:

No es la herramienta ideal para scripts robustos —ya hemos dicho que command -v gana ahí—, pero en el flujo diario resulta comodísimo.

Encontrar el ejecutable correcto cambia más de lo que parece

Desarrollar, administrar sistemas o simplemente mantener en orden tu portátil no va de heroísmos. Va de observabilidad cotidiana. which es una lupa pequeña y exacta que te dice qué binario pisa el escenario cuando escribes un nombre. Pone luz sobre el $PATH, revela conflictos, marca prioridades y reduce la probabilidad de ejecutar algo distinto a lo que creías.

Combínalo con type para ver si un nombre es alias o builtin, con command -v cuando escribas scripts y con readlink -f si quieres seguir el hilo hasta el final. Con ese repertorio, las sorpresas se vuelven raras y los diagnósticos, rápidos. Y, sobre todo, tus horas cunden más. Porque saber qué se ejecuta y desde dónde no es un capricho de power user: es higiene básica para cualquier persona que pisa la línea de comandos a diario.

🔎​ Contenido Verificado ✔️

Este artículo ha sido redactado basándose en información procedente de fuentes oficiales y confiables, garantizando su precisión y actualidad. Fuentes consultadas: Red Hat, Oracle Solaris, GNU Coreutils, Debian Manpages.