Bir sistem yöneticisi olarak günün birinde bir yazılımın nerede kurulu olduğunu, man sayfasının hangi dizinde yattığını ya da kaynak kodunun sistemde olup olmadığını bulmak zorunda kaldığını hepimiz biliriz. İşte tam bu noktada whereis komutu devreye girer. Basit görünse de doğru kullanıldığında ciddi zaman kazandıran bu araç, hakkında yeterince yazı yazılmamış komutların başında gelir. Bu yazıda whereis komutunu tüm yönleriyle ele alacağız.
whereis Nedir ve Ne İşe Yarar?
whereis komutu, bir programın ikili dosyasını (binary), man sayfasını ve kaynak kodunu sistemde bulup raporlayan bir araçtır. which komutundan farklı olarak sadece PATH içinde arama yapmaz; önceden tanımlanmış bir dizi dizinde arama gerçekleştirir. Bu sayede tek bir komutla programla ilgili birden fazla konumu öğrenebilirsiniz.
Komutun temel sözdizimi şu şekildedir:
whereis [seçenekler] program_adı
Hızlı bir örnek verelim:
whereis bash
Bu komutun çıktısı genellikle şöyle görünür:
bash: /bin/bash /usr/share/man/man1/bash.1.gz
Tek satırda hem programın ikili dosyasının yerini hem de man sayfasının konumunu öğrendik. Çok pratik, değil mi?
whereis vs which vs find: Kafalar Karışmasın
Bu üç komut birbiriyle sık sık karıştırılır. Aralarındaki farkı net şekilde ortaya koymak gerekirse:
- which: Yalnızca PATH değişkenindeki dizinleri tarar ve çalıştırılabilir dosyanın tam yolunu verir. Hızlıdır ama sınırlıdır.
- whereis: Önceden tanımlanmış dizinlerde binary, man sayfası ve source kodunu arar. PATH bağımsız çalışır.
- find: Tüm dosya sistemini tarayabilir, çok güçlüdür ama yavaştır ve sözdizimi daha karmaşıktır.
Aşağıdaki örnek bu farkı güzel gösteriyor:
which python3
# Çıktı: /usr/bin/python3
whereis python3
# Çıktı: python3: /usr/bin/python3 /usr/lib/python3 /etc/python3 /usr/share/man/man1/python3.1.gz
find / -name python3 2>/dev/null
# Çıktı: Dakikalar sürebilir, onlarca sonuç döner
Gördüğünüz gibi whereis, which‘e kıyasla çok daha fazla bilgi verirken find‘a kıyasla çok daha hızlı çalışır.
Temel Kullanım Parametreleri
whereis komutunun birkaç önemli parametresi var. Bunları öğrenmek komutu çok daha verimli kullanmanızı sağlar:
- -b: Yalnızca binary (ikili) dosyaları arar
- -m: Yalnızca man sayfalarını arar
- -s: Yalnızca kaynak kod dosyalarını arar
- -u: Olağandışı girişleri bulur; yani binary, man veya source’dan herhangi biri eksik olan programları listeler
- -B dizin: Binary araması için özel dizin belirtir
- -M dizin: Man sayfası araması için özel dizin belirtir
- -S dizin: Kaynak kod araması için özel dizin belirtir
- -f: Dizin listesini sonlandırır, ardından program adları gelir (özellikle -B, -M, -S ile birlikte kullanılır)
- -l: Arama yapılan dizinleri listeler
Sadece Binary Dosyasını Bulmak
Bazen sadece programın çalıştırılabilir dosyasının nerede olduğunu öğrenmek istersiniz, geri kalanlar sizi ilgilendirmez:
whereis -b nginx
# Çıktı: nginx: /usr/sbin/nginx
Bu özellikle script yazarken işe yarar. Programın var olup olmadığını kontrol etmek için kullanabilirsiniz.
Sadece Man Sayfalarını Bulmak
Dokümantasyon dosyalarının nerede olduğunu bulmak için:
whereis -m ssh
# Çıktı: ssh: /usr/share/man/man1/ssh.1.gz
Bir programın birden fazla bölümde man sayfası olabilir. whereis -m bunların hepsini tek seferde gösterir.
Arama Dizinlerini Görüntülemek
whereis hangi dizinlere bakıyor merak ediyorsanız:
whereis -l
Bu komut oldukça uzun bir liste döner. Sistemde tipik olarak /usr/bin, /usr/sbin, /bin, /sbin, /usr/share/man, /usr/local/bin gibi onlarca dizin listelenir. Bu bilgi, neden bazı programların whereis tarafından bulunamadığını anlamak için kritiktir.
Gerçek Dünya Senaryoları
Teorik bilgi güzel, ama sysadmin’lerin işine asıl yarayan pratik örnekler. İşte günlük işlerde karşılaşılan durumlar:
Senaryo 1: Birden Fazla PHP Sürümü Yüklü Sistem
Bir web sunucusunda PHP 7.4 ve PHP 8.1 bir arada kurulu. Hangi PHP binary’lerinin nerede olduğunu öğrenmek için:
whereis php
# Çıktı: php: /usr/bin/php /usr/bin/php8.1 /usr/bin/php7.4 /usr/share/man/man1/php.1.gz
Tek komutla tüm PHP binary’lerini gördük. Artık hangi sürümü kullandığımızı ve alternatiflerin nerede olduğunu biliyoruz. Hatta şunu yapabiliriz:
whereis php php7.4 php8.1 php-fpm
Birden fazla program adını aynı anda whereis‘e verebilirsiniz. Çıktı her biri için ayrı satırda gelir.
Senaryo 2: Konfigürasyon Sorunlarını Araştırma
Nginx kurulu ama beklenmedik davranışlar var. Sisteme daha önce kim kurmuş, hangi binary çalışıyor bilmiyorsunuz:
whereis nginx
# Çıktı: nginx: /usr/sbin/nginx /usr/sbin/nginx /etc/nginx /usr/share/man/man8/nginx.8.gz
Burada /etc/nginx de listeye girdi, bu konfigürasyon dizini. whereis bazen konfigürasyon dosyaları da döndürebilir çünkü bu dizin arama listesindedir. Aynı dizinin iki kez görünmesi ise sembolik link durumuna işaret edebilir.
Senaryo 3: Eksik Dokümantasyon Tespiti
Minimal kurulum yapılmış bir sunucuda hangi programların man sayfası yok? -u parametresi tam burada parlıyor:
whereis -m -u /usr/bin/*
Bu komut, /usr/bin/ içindeki hangi programların man sayfası olmadığını listeler. Minimal Docker imajlarında ya da stripped-down sistemlerde bu liste oldukça kabarık olabilir.
Senaryo 4: Script İçinde Varlık Kontrolü
Bir deployment scripti yazıyorsunuz ve gerekli araçların sistemde kurulu olup olmadığını kontrol etmeniz gerekiyor:
#!/bin/bash
check_binary() {
local program=$1
local result=$(whereis -b "$program" | awk '{print $2}')
if [ -z "$result" ]; then
echo "HATA: $program bulunamadı, lütfen kurun."
exit 1
else
echo "OK: $program -> $result"
fi
}
check_binary git
check_binary docker
check_binary curl
check_binary jq
Bu script çalıştırıldığında her araç için ya “OK” çıktısı ve yolunu ya da hata mesajı alırsınız. Deployment öncesi hızlı bir sanity check için mükemmel.
Senaryo 5: Özel Dizinde Arama
Kullanıcının home dizinine kurulmuş programlar veya özel dizinlerdeki binary’leri aramak istiyorsunuz:
whereis -B /opt/custom/bin /home/deploy/bin -f myapp
-f parametresinin rolünü anlamak önemli: -B ile verilen dizin listesinin nerede bittiğini söylüyorsunuz programa. Bu olmadan whereis dizin adlarını program adı olarak yorumlayabilir.
Senaryo 6: Java Kurulumlarını Tespit Etme
Java dünyası kaotiktir. OpenJDK, Oracle JDK, farklı sürümler… Hepsini bir anda görmek için:
whereis java javac javap jar
Çıktı şöyle olabilir:
java: /usr/bin/java /usr/share/java /usr/share/man/man1/java.1.gz
javac: /usr/bin/javac /usr/share/man/man1/javac.1.gz
javap: /usr/bin/javap /usr/share/man/man1/javap.1.gz
jar: /usr/bin/jar /usr/share/man/man1/jar.1.gz
whereis’in Çalışma Mekanizması
whereis nasıl bu kadar hızlı çalışıyor diye merak edebilirsiniz. Cevap basit: indeksleme yapmaz ve veritabanı kullanmaz. Sadece önceden hardcode edilmiş ya da sistem konfigürasyonundan okunan dizin listesini tarar. Bu liste /etc/manpath.config gibi dosyalardan ve derleme zamanında belirlenen sabit değerlerden gelir.
locate komutu gibi bir veritabanını güncellemek zorunda değilsiniz. find gibi tüm dosya sistemini dolaşmaz. Sadece “program genellikle buralarda olur” mantığıyla belirli dizinlere bakar. Bu yaklaşım hız sağlar ama sınırlılık da getirir: olağandışı konumlara kurulmuş programları bulamayabilir.
Sınırlılıkları ve Dikkat Edilmesi Gerekenler
whereis her derde deva değil. Şu durumları aklınızda tutun:
PATH dışı kurulumlar: Kullanıcı kendi home dizinine bir araç kurmuşsa ve bu dizin whereis‘in arama listesinde yoksa, bulamaz. -B parametresi ile ek dizin eklemek gerekir.
Snap ve Flatpak paketleri: Modern Linux dağıtımlarında snap ile kurulmuş uygulamalar /snap/bin altında olur. Bu dizin whereis‘in standart listesinde genellikle yoktur. which snap-app-name daha iyi sonuç verebilir.
# Snap kurulu bir uygulama için:
which code # Visual Studio Code snap olarak kurulmuşsa bulur
whereis code # Bulamayabilir veya eksik bilgi döner
Alias ve shell fonksiyonları: whereis shell alias’larını bilmez. bash built-in komutlarını da bulamaz. type komutu bu konuda daha kapsamlıdır.
type ll # ll alias'ının ne olduğunu söyler
whereis ll # Hiçbir şey bulamaz
Güncellenen sistemler: Yeni kurulan bir paket hemen whereis tarafından bulunmalıdır çünkü whereis veritabanı kullanmaz. Ama locate kullanıyorsanız updatedb çalıştırmanız gerekebilir.
Çıktıyı İşlemek: Awk ve Sed ile Kombinasyon
whereis çıktısı makine tarafından işlenmeye pek uygun değil ilk bakışta, ama biraz awk ile güzel şeyler yapılabilir:
# Sadece binary yolunu almak
whereis -b python3 | awk '{print $2}'
# Birden fazla sonuç varsa hepsini ayrı satırlarda listele
whereis python | tr ' ' 'n' | grep -v ':' | grep -v '^$'
# Hangi programların birden fazla binary lokasyonu var?
for cmd in python python3 pip pip3; do
count=$(whereis -b $cmd | awk '{print NF-1}')
echo "$cmd: $count binary lokasyonu"
done
Son örnek çok işlevsel. Bir sistemde hangi araçların birden fazla binary kopyasına sahip olduğunu gösterir. Bu bazen beklenmedik davranışların kaynağıdır.
Pratik Alias ve Fonksiyonlar
Günlük kullanımı kolaylaştırmak için .bashrc veya .zshrc dosyanıza şunları ekleyebilirsiniz:
# Hızlı program bilgisi
alias wi='whereis'
alias wib='whereis -b'
alias wim='whereis -m'
# Programın tüm bilgilerini güzel formatta göster
proginfo() {
echo "=== $1 Bilgileri ==="
echo "Binary : $(whereis -b $1 | cut -d' ' -f2-)"
echo "Man : $(whereis -m $1 | cut -d' ' -f2-)"
echo "Which : $(which $1 2>/dev/null || echo 'PATH içinde yok')"
echo "Type : $(type $1 2>/dev/null | head -1)"
}
proginfo nginx şeklinde çalıştırıldığında tek bir araç hakkında toplu bilgi alırsınız.
Diğer Araçlarla Karşılaştırmalı Kullanım
Gerçek bir troubleshooting senaryosunda sadece whereis kullanmazsınız. İşte tipik bir araştırma akışı:
# 1. Adım: Program var mı ve nerede?
whereis curl
# 2. Adım: PATH'te hangi curl kullanılıyor?
which curl
# 3. Adım: Bu gerçekten ne? (symlink mi, binary mi?)
ls -la $(which curl)
# 4. Adım: Hangi paket kurdu bunu?
dpkg -S $(which curl) # Debian/Ubuntu
rpm -qf $(which curl) # RHEL/CentOS
# 5. Adım: Sürüm ne?
curl --version
Bu akış, herhangi bir programla ilgili neredeyse tüm temel soruları cevaplar.
Farklı Dağıtımlarda whereis Davranışı
whereis util-linux paketinin bir parçasıdır ve neredeyse tüm Linux dağıtımlarında hazır gelir. Ama arama dizin listeleri dağıtıma göre farklılık gösterebilir.
Ubuntu/Debian sistemlerde binary’ler genellikle /usr/bin ve /bin altındayken, RHEL tabanlı sistemlerde benzer bir düzen vardır ama bazı ince farklar olabilir. Modern sistemlerde /bin, /usr/bin‘in sembolik linki olmuştur ve bu whereis çıktısında bazen çifte sonuç olarak görünür.
# Ubuntu 22.04 örneği:
whereis ls
# ls: /usr/bin/ls /usr/share/man/man1/ls.1.gz
# CentOS 7 örneği:
whereis ls
# ls: /usr/bin/ls /bin/ls /usr/share/man/man1/ls.1.gz
CentOS 7’de /bin henüz /usr/bin‘in symlink’i olmadığı için iki ayrı sonuç çıkabilir.
whereis ile Sistem Denetimi
Toplu sistem denetimi için whereis güzel bir araç olabilir. Örneğin kritik sistem araçlarının tamamının varlığını kontrol eden bir script:
#!/bin/bash
KRITIK_ARACLAR="sshd cron rsyslogd iptables firewalld fail2ban"
echo "Kritik Araç Denetimi - $(date)"
echo "================================"
for arac in $KRITIK_ARACLAR; do
binary=$(whereis -b "$arac" | awk '{print $2}')
if [ -n "$binary" ]; then
echo "[OK] $arac -> $binary"
else
echo "[EKS] $arac -> BULUNAMADI"
fi
done
Bu script, sistem kurulumu sonrasında ya da düzenli bakım çerçevesinde kritik servislerin varlığını doğrulamak için kullanılabilir.
Sonuç
whereis komutu, sysadmin araç kutusunun mütevazı ama değerli bir üyesidir. Karmaşık değil, bağımlılığı yok, çabuk öğreniliyor. Ama doğru zamanda doğru şekilde kullanıldığında ciddi zaman kazandırıyor.
Özetlemek gerekirse: bir programın binary’sini, man sayfasını ve kaynak kodunu tek seferde görmek istediğinizde whereis tam aradığınız şey. PATH bağımsız çalışması, hızı ve çıktısının sade olması güçlü yanları. Snap/flatpak gibi modern paket sistemlerini takip edememesi, alias ve shell built-in’leri görmemesi ise bilinen sınırlılıkları.
Ama şunu söyleyeyim: which, whereis, type, find komutlarının hepsini birbirinin yerine değil, birbirinin tamamlayıcısı olarak düşünün. Her birinin güçlü olduğu bir senaryo var. Hangisini ne zaman kullanacağınızı bilmek, terminal üretkenliğinizi gerçekten artırır.
Bir dahaki troubleshooting seansınızda, refleks olarak find / -name program yazmadan önce önce whereis program deneyin. Çok daha hızlı ve çoğu zaman yeterince detaylı bir cevap alacaksınız.