51 05/04/2026 07/04/2026 7 min

whereis: cosa fa davvero

whereis serve a trovare rapidamente i componenti associati a un comando: binario, sorgenti e pagine di manuale. È utile quando vuoi verificare dove vive un eseguibile, confrontare più installazioni o capire se un tool è presente sul sistema senza dover scandagliare a mano l’intero filesystem.

Non è un sostituto di find o locate. Fa una ricerca mirata, basata su percorsi standard e su un database interno di directory note. Questo lo rende veloce, ma anche meno “onnisciente” di una scansione completa.

In pratica, whereis risponde a domande del tipo: dov’è il binario di nginx? Esiste la man page? Ci sono sorgenti installate? Per troubleshooting, inventory veloce e controllo di coerenza è uno strumento comodo e immediato.

Sintassi di base

La forma più semplice è questa:

whereis nome_comando

Per esempio:

whereis php

L’output tipico può includere più campi:

  • bin: binario o eseguibile
  • man: manuale
  • src: sorgenti, se presenti

Un output realistico potrebbe somigliare a questo:

php: /usr/bin/php /usr/share/man/man1/php.1.gz

Qui vedi subito che il comando è disponibile e dove si trova la documentazione. Se il sistema ha più versioni o installazioni parallele, il risultato può contenere più percorsi.

Perché usarlo invece di which o command -v

Molti confondono whereis con which o command -v. La differenza è concreta:

  • command -v ti dice quale comando verrebbe eseguito dalla shell nel PATH corrente
  • which fa una verifica simile, ma è meno standard e dipende dall’implementazione
  • whereis cerca anche man page e sorgenti, non solo il binario nel PATH

Quindi, se vuoi sapere “che binario userà la shell adesso”, usa command -v. Se vuoi una vista più ampia dei componenti associati al pacchetto/comando, usa whereis.

Esempio pratico:

command -v python3
whereis python3

Il primo mostra il percorso effettivo risolto dalla shell; il secondo può aggiungere la man page e altre copie del binario presenti in path standard.

Opzioni più utili

whereis ha poche opzioni, ma quelle giuste coprono buona parte dei casi d’uso.

-b: cerca solo i binari

Se ti interessa solo l’eseguibile:

whereis -b nginx

Utile quando vuoi evitare rumore da man page o sorgenti.

-m: cerca solo i manuali

Per vedere se esiste la documentazione:

whereis -m nginx

Comodo in ambienti minimi o container dove il binario c’è ma la documentazione manca.

-s: cerca solo i sorgenti

Se vuoi sapere se sono presenti sorgenti locali:

whereis -s nginx

In molti sistemi moderni non restituirà nulla, ed è normale: i sorgenti non sono quasi mai installati sul server di produzione.

-u: mostra solo elementi insoliti

Questa opzione è meno nota ma utile per audit rapido. Mostra i file che non rientrano nei percorsi standard attesi.

whereis -u nginx

Se ottieni output, vale la pena indagare: potrebbe esserci una installazione custom, una copia duplicata o un path non standard.

-l: elenca i percorsi di ricerca

Per capire dove whereis sta cercando:

whereis -l

Molto utile per debug quando il comando non trova ciò che ti aspetti. Ti mostra le directory considerate dal tool.

-B, -M, -S: personalizzare i path di ricerca

Queste opzioni permettono di forzare directory specifiche per binari, manuali e sorgenti.

whereis -B /opt/bin -M /opt/man -S /opt/src nginx

È utile quando lavori in ambienti con layout non standard, build locali o installazioni in /opt.

Se non passi i percorsi giusti, whereis non può indovinare dove hai messo i file. Questo è uno dei limiti principali dello strumento.

Esempi pratici di uso quotidiano

Un check veloce su un servizio web:

whereis apache2
whereis httpd
whereis nginx

Su Debian/Ubuntu potresti vedere apache2; su RHEL/CentOS/Alma/Rocky più facilmente httpd. Questo già ti aiuta a capire quale naming convention usa la distro.

Verifica di un runtime PHP:

whereis php
whereis php-fpm

Se il binario c’è ma php-fpm non compare, potresti avere solo CLI installato e non il demone FPM.

Controllo di strumenti di sistema:

whereis systemctl
whereis journalctl
whereis ssh

Qui il risultato è spesso banale, ma utile quando devi capire rapidamente se stai lavorando in un container minimale o in un host completo.

Verifica di software installato manualmente:

whereis node
whereis java
whereis python3

Se hai più versioni installate, whereis può restituire più path e aiutarti a notare collisioni o installazioni parallele.

Come interpretare l’output

L’output è una lista di coppie chiave-valore implicite, separate da spazi. Non sempre tutte le categorie sono presenti. Un risultato vuoto non significa necessariamente che il software non esiste: può voler dire che non è installato in percorsi standard o che il nome cercato non corrisponde al nome reale del pacchetto/binario.

Per esempio:

whereis nginx

Potresti ottenere:

nginx: /usr/sbin/nginx /etc/nginx /usr/share/man/man8/nginx.8.gz

Qui c’è un dettaglio importante: oltre al binario, compare anche la directory di configurazione. Non sempre succede, ma quando succede è utile per capire dove si trovano i file principali del servizio.

Se invece vedi qualcosa come:

nginx:

significa che whereis non ha trovato corrispondenze nei suoi percorsi. A quel punto conviene passare a:

  • command -v nginx per vedere se la shell lo risolve
  • rpm -qa | grep nginx o dpkg -l | grep nginx per verificare il pacchetto
  • find / -name nginx solo se serve davvero e con cautela, perché è più costoso

Limiti pratici da conoscere

whereis è rapido, ma non fa magie. I limiti principali sono questi:

  • cerca in percorsi standard o configurati, non in tutto il filesystem
  • non è affidabile per installazioni custom fuori dai path attesi, a meno di usare -B, -M, -S
  • può restituire più risultati se esistono più copie del comando
  • non ti dice quale versione è attiva nella sessione corrente

Per questo, in troubleshooting serio, whereis va usato come primo indizio, non come prova definitiva.

Se stai gestendo un server con più ambienti, ad esempio un binario in /usr/bin e uno in /usr/local/bin, whereis può mostrarti entrambi. Ma per sapere quale viene eseguito davvero devi guardare il PATH oppure usare:

command -v nome_comando
which nome_comando

whereis in automazione e troubleshooting

In script semplici o playbook rapidi, whereis può servire per validazioni basilari. Per esempio, puoi verificare la presenza di documentazione o binari prima di procedere con un’operazione di manutenzione.

Esempio di controllo minimale:

if whereis -b nginx | grep -q '/'; then
  echo "nginx presente"
else
  echo "nginx assente"
fi

È una soluzione semplice, ma non la userei come unica fonte in automazioni critiche. Se serve robustezza, meglio interrogare il package manager, il systemd unit state o il path effettivo del binario.

In troubleshooting, può aiutare a capire subito se il problema è “il comando non esiste” oppure “il comando esiste ma non è quello che credi”. Per esempio, se whereis php mostra /usr/bin/php ma la shell usa un’altra versione, il problema è quasi certamente nel PATH o in un alias/symlink.

Confronto rapido con altri strumenti

command -v è il più adatto per capire quale eseguibile verrà lanciato dalla shell.

whereis è il più utile per avere una vista sintetica di binario, man e sorgenti.

locate è più ampio e dipende dal database aggiornato dal sistema; è ottimo per ricerche veloci, ma non sempre aggiornato in tempo reale.

find è il più accurato, ma anche il più costoso in termini di tempo e I/O.

In pratica:

  • se vuoi velocità e un quadro sintetico, usa whereis
  • se vuoi sapere cosa esegue la shell, usa command -v
  • se vuoi cercare ovunque, usa find
  • se vuoi consultare un indice, usa locate

Buone pratiche operative

Quando usi whereis in amministrazione di sistema, tieni a mente alcuni punti:

  • non assumere che l’output rappresenti la versione attiva
  • verifica sempre il contesto della shell o del servizio
  • usa -u per individuare file fuori standard, soprattutto in ambienti eterogenei
  • se lavori con path custom, specifica -B, -M, -S

Per esempio, se hai installato software in /opt o in una directory applicativa dedicata, il comportamento di default può non bastare. In quel caso conviene adattare la ricerca al layout reale del sistema.

Regola pratica: whereis è ottimo per orientarsi, non per chiudere un’analisi da solo.

Esempi finali da copiare al volo

whereis nginx
whereis -b nginx
whereis -m nginx
whereis -u nginx
whereis -l
command -v nginx

Con questi comandi copri i casi principali: presenza del binario, manuale, elementi insoliti, percorsi di ricerca e confronto con la risoluzione della shell.

Se devi fare assistenza operativa su Linux, whereis è uno di quei comandi piccoli ma utili che vale la pena tenere in tasca: rapido, leggibile, poco invasivo. Usato bene, ti fa risparmiare tempo nelle verifiche iniziali e ti evita ricerche inutili quando devi capire in fretta dove si trova un programma e cosa è stato installato sul sistema.

Assunzione: gli esempi sono validi su distribuzioni Linux comuni con whereis installato dal pacchetto standard util-linux o equivalente.