Whereis sous Linux : retrouver un binaire et son manuel

Vous venez d’installer un outil, mais vous ne savez plus s’il se trouve dans /usr/bin, /usr/local/bin ou ailleurs. La commande whereis peut retrouver son binaire, ses sources et ses pages de manuel. Elle ne répond toutefois pas à la question la plus importante avant une intervention : quel fichier votre shell va-t-il réellement exécuter ?

Pour éviter de modifier la mauvaise installation, je croise whereis avec command -v et type. Ces commandes ne cherchent pas la même chose. Cette différence devient vite utile quand plusieurs versions d’un programme, un alias ou une fonction Bash portent le même nom.

Ce que whereis cherche réellement

L’utilisation la plus simple consiste à fournir le nom d’une commande, sans option :

whereis bash
whereis ssh
whereis nginx

La sortie peut contenir plusieurs chemins sur la même ligne. whereis cherche trois types de fichiers : le binaire, les sources et la documentation de manuel. Il examine des emplacements Linux connus, puis tient aussi compte de PATH et de MANPATH. Il ne se contente donc pas de parcourir les exécutables que votre shell peut lancer.

Vous pouvez limiter la recherche au type qui vous intéresse :

whereis -b bash
whereis -m bash
whereis -s bash

• -b cherche les binaires ;
• -m cherche les pages de manuel et les fichiers Info ;
• -s cherche les sources.

Une recherche de sources vide n’indique pas que le programme est mal installé. Les distributions installent souvent le binaire et le manuel sans déposer le code source sous /usr/src. Pour voir les dossiers effectivement inspectés sur votre machine, utilisez :

whereis -l

La page de manuel de whereis détaille ces chemins et les options disponibles. Cette commande n’est pas une recherche récursive de fichiers. Pour retrouver un fichier arbitraire dans une arborescence, utilisez plutôt le guide sur find sous Linux.

Vérifier la commande réellement lancée par le shell

Si votre objectif est de savoir ce qui partira lorsque vous tapez python3, nginx ou monoutil, commencez par command -v :

command -v python3
command -v nginx
command -v monoutil

Cette commande suit la résolution du shell. Selon le nom fourni, elle peut afficher le chemin d’un exécutable, un builtin, une fonction ou la définition d’un alias. Son code de retour permet aussi de vérifier proprement la présence d’une commande dans un script :

if command -v monoutil >/dev/null 2>&1; then
    echo "monoutil est disponible"
else
    echo "monoutil est introuvable" >&2
fi

N’utilisez pas whereis pour ce test. Quand aucun fichier ne correspond, il peut simplement afficher le nom suivi de deux-points et terminer avec un code de retour nul. Le script conclurait alors à tort que la commande existe.

type va plus loin en expliquant comment Bash interprète le nom :

type cd
type ls
type -a ls
type -P ls

• type cd indique que cd est une commande interne du shell ;
• type ls montre la première définition utilisée ;
• type -a ls affiche les alias, fonctions, builtins et exécutables portant ce nom ;
• type -P ls force une recherche de fichier exécutable dans PATH.

La documentation GNU Bash de type décrit précisément ces résultats. Si vous utilisez Zsh, Fish ou un autre shell, contrôlez sa propre documentation : la résolution des alias et fonctions n’est pas identique partout.

Comprendre pourquoi which ne donne pas toute l’histoire

which reste courant dans les tutoriels :

which python3
which nginx

Il cherche généralement un exécutable dans PATH. Le problème est qu’il s’agit souvent d’un programme externe qui ne connaît pas exactement l’état du shell courant. Selon l’implémentation et la distribution, il peut ignorer un alias, une fonction ou un builtin. Pour un test dans un script shell, command -v est plus adapté. Pour comprendre une collision de noms dans une session interactive, type -a donne davantage d’informations.

Un exemple simple permet de voir la différence :

alias ll='ls -lah'
whereis ll
which ll
command -v ll
type ll

whereis ne retrouve pas un fichier nommé ll, car l’alias n’est pas un binaire. command -v et type voient en revanche la définition connue de Bash. L’article sur les alias sous Linux explique comment les vérifier et les contourner sans supprimer votre configuration.

Repérer plusieurs installations du même programme

Les collisions arrivent souvent après une installation manuelle dans /usr/local/bin, l’ajout de $HOME/.local/bin ou le déploiement d’une version dans /opt. Commencez par comparer les résultats :

whereis python3
type -a python3
command -v python3
type -P python3
readlink -f "$(type -P python3)"

whereis peut afficher plusieurs binaires et manuels. type -a montre les versions que Bash trouve dans l’ordre de résolution. command -v confirme le premier choix, puis readlink -f résout un éventuel lien symbolique. Vérifiez enfin le paquet propriétaire du fichier :

dpkg -S "$(type -P python3)"
rpm -qf "$(type -P python3)"
pacman -Qo "$(type -P python3)"

N’exécutez que la commande adaptée à votre distribution. Si aucun paquet ne possède le fichier, il peut provenir d’une installation manuelle. Avant de le remplacer, retrouvez sa version, sa cible réelle et les services qui l’utilisent. Le tutoriel sur les archives tar.gz sous Linux montre pourquoi une copie dans /usr/local/bin doit rester traçable.

Bash mémorise aussi certains chemins déjà résolus. Après avoir déplacé ou remplacé un exécutable, videz ce cache puis contrôlez à nouveau :

hash -l
hash -r
command -v python3
type -a python3

Si le mauvais fichier passe en premier, corrigez l’ordre de PATH plutôt que de supprimer un binaire au hasard. Le guide sur PATH sous Linux détaille le test temporaire et la modification durable.

Limiter whereis à un dossier précis

Pour contrôler un logiciel installé sous /opt, vous pouvez remplacer les chemins de recherche des binaires ou des manuels. L’option -f marque la fin de la liste des dossiers et le début des noms à chercher :

whereis -b -B /opt/monoutil/bin /usr/local/bin -f monoutil
whereis -m -M /opt/monoutil/share/man -f monoutil

Cette recherche ciblée permet de vérifier le contenu d’une installation sans parcourir tout le disque. Elle ne change ni PATH, ni la commande exécutée par le shell. Gardez donc l’ordre suivant avant de retirer ou remplacer un programme :

• utilisez command -v pour connaître la définition active ;
• lancez type -a pour repérer les collisions ;
• résolvez les liens avec readlink -f ;
• contrôlez le paquet propriétaire du fichier ;
• utilisez whereis pour retrouver les binaires et la documentation associés.

Avec ces vérifications, vous savez quel fichier sera lancé, d’où il vient et où lire son manuel. Vous pouvez alors corriger une installation ou un PATH sans effacer la bonne version par erreur.

sudo apt update && sudo apt upgrade