Direktori Biner Linux Dijelaskan: Referensi Teknis Lengkap

Direktori biner Linux adalah lokasi filesystem terstandarisasi tempat program yang dapat dieksekusi, alat administrasi sistem, dan pustaka bersama berada. Filesystem Hierarchy Standard (FHS) mendefinisikan jalur-jalur ini untuk memastikan penempatan perangkat lunak yang konsisten di seluruh distribusi, memungkinkan resolusi `PATH` yang dapat diprediksi, manajemen paket yang bersih, dan pemulihan sistem yang andal — bahkan ketika filesystem non-esensial tidak tersedia.

Bagi setiap administrator yang mengelola lingkungan VPS Hosting atau server bare-metal, mengetahui dengan tepat biner mana yang berada di mana — dan mengapa — bukanlah pengetahuan yang opsional. Hal ini secara langsung memengaruhi perilaku boot, pemisahan hak istimewa, strategi penerapan perangkat lunak, dan penguatan keamanan.

Mengapa Struktur Direktori Biner Penting

Sebelum mendalami direktori individual, ada baiknya memahami logika arsitektur di balik pemisahan tersebut. FHS membagi filesystem menjadi dua sumbu fundamental:

• Esensial vs. non-esensial: Biner yang diperlukan untuk mode pengguna tunggal dan perbaikan darurat harus tersedia sebelum `/usr` dipasang. Semua yang lain dapat berada di bawah `/usr`.
• Tingkat sistem vs. pengguna: Biner yang ditujukan untuk administrasi tingkat root dipisahkan dari yang tersedia untuk pengguna tanpa hak istimewa, memungkinkan kontrol akses yang lebih ketat melalui izin filesystem.

Filosofi desain ini mendahului sistem init modern, tetapi tetap sangat relevan. `PATH` yang salah dikonfigurasi, biner yang ditempatkan di direktori yang salah, atau symlink pustaka yang hilang dapat secara diam-diam merusak urutan boot, cron job, atau skrip startup layanan.

Sekilas tentang Direktori Biner Inti

/bin — Biner Pengguna Esensial

`/bin` menyimpan kumpulan minimal executable yang diperlukan agar sistem dapat melakukan boot dan agar pengguna dapat melakukan operasi dasar dalam mode pengguna tunggal atau mode penyelamatan. Biner-biner ini harus dapat diakses bahkan ketika hanya filesystem root yang dipasang.

Contoh kanonik: `ls`, `cp`, `mv`, `cat`, `bash`, `echo`, `grep`, `chmod`, `ln`, `mkdir`, `rm`, `ps`

Detail teknis penting: Pada distribusi berbasis systemd — termasuk Debian 10+, Ubuntu 20.04+, Fedora, Arch Linux, dan RHEL 8+ — `/bin` kini merupakan symbolic link yang menunjuk ke `/usr/bin`. Ini adalah bagian dari inisiatif UsrMerge, yang mengkonsolidasikan direktori biner tingkat root ke dalam padanannya di `/usr` untuk menyederhanakan desain initramfs dan memungkinkan pembaruan OS secara atomik. Anda dapat memverifikasi ini pada sistem yang telah digabungkan:

“`bash

ls -la /bin

lrwxrwxrwx 1 root root 7 /bin -> usr/bin

“`

Implikasi operasional: Jika Anda menulis skrip shell yang dimaksudkan untuk berjalan di lingkungan penyelamatan atau hook boot awal (misalnya, skrip initramfs), jangan pernah berasumsi bahwa `/usr/bin` tersedia. Selalu gunakan `/bin/sh` sebagai shebang Anda dan hanya referensikan utilitas yang diamanatkan POSIX.

/sbin — Biner Sistem Esensial

`/sbin` berisi biner yang dicadangkan untuk tugas administrasi sistem yang harus dapat dieksekusi selama boot dan operasi perbaikan filesystem, sebelum pohon filesystem penuh tersedia.

Contoh kanonik: `fsck`, `ifconfig`, `ip`, `reboot`, `shutdown`, `mkfs`, `mount`, `umount`, `fdisk`, `modprobe`, `init`

Nuansa hak istimewa: Meskipun biner `/sbin` *dimaksudkan* untuk penggunaan root, biner-biner tersebut dapat dieksekusi oleh semua orang pada sebagian besar distribusi. Pembatasan diberlakukan oleh operasi itu sendiri — `fsck` memerlukan akses perangkat mentah, `mount` memerlukan `CAP_SYS_ADMIN` — bukan oleh bit eksekusi biner. Ini adalah sumber kebingungan yang umum selama audit keamanan.

Status modern: Seperti `/bin`, `/sbin` adalah symlink ke `/usr/sbin` pada sistem merged-usr. Perbedaan antara `/sbin` dan `/bin` kini lebih bersifat semantik dan historis daripada struktural.

/usr/bin — Repositori Biner Pengguna Utama

`/usr/bin` adalah direktori biner terbesar dan paling sering diakses pada instalasi Linux yang umum. Direktori ini berisi semua utilitas baris perintah standar yang menghadap pengguna dan aplikasi yang diinstal melalui manajer paket sistem yang tidak diperlukan untuk operasi darurat.

Contoh kanonik: `vim`, `nano`, `git`, `python3`, `perl`, `gcc`, `curl`, `wget`, `ssh`, `tar`, `gzip`, `awk`, `sed`, `find`

Skala dalam praktik: Pada instalasi server Debian minimal, `/usr/bin` mungkin berisi 200–400 biner. Instalasi lingkungan desktop penuh dapat mendorong angka tersebut di atas 2.000. Direktori ini selalu ada dalam `PATH` default untuk semua pengguna.

Kepemilikan manajer paket: Setiap file di sini dilacak oleh `dpkg`, `rpm`, atau padanan distribusi Anda. Menempatkan file secara manual di `/usr/bin` sangat tidak disarankan — pembaruan paket dapat menimpanya secara diam-diam tanpa peringatan.

/usr/sbin — Biner Administrasi Sistem Non-Esensial

`/usr/sbin` berisi alat administrasi sistem yang tidak diperlukan selama proses boot atau pemulihan mode pengguna tunggal, tetapi sangat penting untuk manajemen server sehari-hari.

Contoh kanonik: `apache2`, `nginx`, `sshd`, `useradd`, `userdel`, `usermod`, `groupadd`, `iptables`, `nftables`, `cron`, `logrotate`, `tcpdump`

Wawasan arsitektur: Pemisahan `/sbin` dan `/usr/sbin` awalnya dirancang agar administrator sistem dapat melakukan boot ke mode pengguna tunggal dan melakukan perbaikan tanpa perlu memasang `/usr`. Dalam praktiknya, pada sistem modern dengan initramfs dan early userspace, perbedaan ini sebagian besar telah runtuh. Namun, memahaminya tetap penting saat bekerja dengan sistem RHEL 6/CentOS 6 yang lebih lama atau lingkungan Linux tertanam di mana `/usr` mungkin benar-benar merupakan partisi terpisah.

/usr/local/bin — Biner Pengguna yang Diinstal Administrator

`/usr/local/bin` adalah lokasi yang tepat untuk biner yang diinstal secara manual — di luar manajer paket sistem — dan yang harus tersedia untuk semua pengguna di sistem.

Kasus penggunaan umum:

• Perangkat lunak yang dikompilasi dari sumber (misalnya, build kustom `nginx` dengan modul non-standar)
• Skrip Python yang diinstal melalui `pip install –prefix=/usr/local`
• Alat CLI pihak ketiga yang didistribusikan sebagai biner mandiri (misalnya, `kubectl`, `helm`, `terraform`, `hugo`)
• Skrip otomasi kustom yang harus bersifat sistem-lebar

Prioritas PATH: Pada sistem yang sesuai FHS standar, `/usr/local/bin` muncul *sebelum* `/usr/bin` dalam `PATH` default. Ini berarti biner yang ditempatkan di sini akan membayangi biner yang dikelola paket dengan nama yang sama. Ini disengaja — memungkinkan kustomisasi lokal untuk menggantikan default distribusi — tetapi juga merupakan sumber bug halus yang sering terjadi ketika versi berbeda.

“`bash

echo $PATH

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

“`

Pertimbangan keamanan: Karena `/usr/local/bin` tidak diaudit oleh manajer paket, biner yang ditempatkan di sini tidak menerima pembaruan keamanan otomatis. Pada server yang menjalankan beban kerja produksi — termasuk yang ada di Dedicated Servers — tetapkan jadwal pembaruan manual atau gunakan alat manajemen konfigurasi (Ansible, Puppet, Chef) untuk melacak dan memperbarui biner-biner ini.

/usr/local/sbin — Biner Sistem yang Diinstal Administrator

`/usr/local/sbin` mencerminkan hubungan antara `/sbin` dan `/bin`, tetapi pada tingkat lokal. Ini adalah lokasi yang tepat untuk alat administrasi sistem yang diinstal secara manual yang memerlukan hak istimewa tinggi atau hanya ditujukan untuk root.

Kasus penggunaan umum:

• Skrip backup kustom yang berjalan sebagai root melalui cron
• Agen pemantauan yang dikompilasi secara manual (misalnya, build kustom `node_exporter`)
• Skrip wrapper administratif yang memanggil system call yang memerlukan hak istimewa
• Utilitas manajemen yang disediakan vendor yang dikirimkan sebagai tarball daripada paket

Disiplin operasional: Pertahankan `README` atau file inventaris di `/usr/local/sbin` yang mendokumentasikan asal, versi, dan prosedur pembaruan setiap biner. Pada infrastruktur bersama, biner yang tidak terdokumentasi di direktori ini merupakan kewajiban keamanan dan auditabilitas.

/opt — Aplikasi Pihak Ketiga Mandiri

`/opt` dirancang untuk paket perangkat lunak yang tidak sesuai dengan tata letak direktori FHS — biasanya aplikasi komersial atau proprietary, suite perangkat lunak besar yang didistribusikan vendor, dan aplikasi yang menggabungkan pustaka mereka sendiri untuk menghindari konflik dependensi.

Contoh kanonik:

• `/opt/google/chrome/` — Browser Google Chrome
• `/opt/lampp/` — Stack XAMPP
• `/opt/pycharm/` — IDE JetBrains PyCharm
• `/opt/gitlab/` — Instalasi GitLab Omnibus
• `/opt/aws/` — AWS CLI v2 dan SSM Agent

Konvensi struktural: Setiap aplikasi di bawah `/opt` harus menempati subdirektorinya sendiri mengikuti pola `/opt/<provider>/` atau `/opt/<package>/`. Biner aplikasi biasanya berada di `/opt/<package>/bin/`, dan vendor diharapkan menginstal symlink di `/usr/local/bin` atau memodifikasi `/etc/profile.d/` untuk menambahkan jalur tersebut.

Kapan menggunakan `/opt` vs. `/usr/local`: Gunakan `/opt` ketika perangkat lunak dikirimkan sebagai bundel mandiri dengan pustaka, konfigurasi, dan direktori datanya sendiri. Gunakan `/usr/local/bin` untuk alat biner tunggal atau skrip yang terintegrasi dengan bersih ke dalam tumpukan pustaka sistem yang ada.

Kasus tepi dunia nyata: GitLab Omnibus diinstal sepenuhnya di bawah `/opt/gitlab/` dan mengelola instans PostgreSQL, Redis, dan Nginx-nya sendiri. Isolasi ini disengaja — mencegah konflik versi dengan layanan tingkat sistem. Namun, ini juga berarti alat pemantauan tingkat sistem tidak akan secara otomatis menemukan proses-proses ini kecuali dikonfigurasi secara eksplisit untuk melihat di `/opt`.

/lib, /usr/lib, /lib64, dan /usr/lib64 — Pustaka Bersama

Direktori-direktori ini berisi file objek bersama (file `.so`) yang menjadi dependensi biner di direktori biner yang sesuai saat runtime. File-file ini tidak dapat dieksekusi dalam pengertian tradisional tetapi dimuat ke dalam memori proses oleh dynamic linker (`ld-linux.so`).

Direktori utama dan perannya:

• `/lib` — Pustaka bersama yang diperlukan oleh biner di `/bin` dan `/sbin`. Pada sistem merged-usr, merupakan symlink ke `/usr/lib`.
• `/usr/lib` — Repositori utama untuk semua pustaka bersama sistem. Di sinilah pustaka yang dikelola paket berada.
• `/lib64` — Varian 64-bit dari `/lib` pada sistem multilib (umum pada x86_64 RHEL/CentOS). Sering kali merupakan symlink ke `/usr/lib64`.
• `/usr/lib64` — Pustaka bersama 64-bit pada distribusi berbasis RPM.
• `/usr/local/lib` — Pustaka yang diinstal bersama perangkat lunak yang dikompilasi secara manual.
• `/usr/lib/x86_64-linux-gnu/` — Jalur pustaka multiarch Debian/Ubuntu, memungkinkan pustaka 32-bit dan 64-bit untuk hidup berdampingan.

Mekanisme linker runtime: Ketika sebuah biner dieksekusi, kernel menyerahkan kendali ke dynamic linker yang ditentukan dalam header ELF (biasanya `/lib64/ld-linux-x86-64.so.2`). Linker menyelesaikan dependensi pustaka bersama menggunakan cache yang dibangun oleh `ldconfig`, yang membaca `/etc/ld.so.conf` dan direktori include-nya. Jika sebuah pustaka diinstal tetapi `ldconfig` belum dijalankan, biner akan gagal dengan kesalahan “shared library not found” meskipun file tersebut ada.

“`bash

After installing a library to /usr/local/lib, always run:

ldconfig

Verify library resolution for a specific binary:

ldd /usr/bin/curl

“`

Jebakan umum: Menginstal pustaka yang dikompilasi secara kustom ke `/usr/local/lib` tanpa menjalankan `ldconfig` setelahnya adalah salah satu penyebab paling sering dari kesalahan “cannot open shared object file” pada server Linux. Ini sangat umum terjadi saat membangun perangkat lunak dari sumber pada VPS dengan cPanel atau lingkungan terkelola serupa di mana proses build mungkin tidak memiliki akses root untuk menjalankan `ldconfig`.

UsrMerge: Konsolidasi Filesystem Modern

Inisiatif UsrMerge (atau `usr-merge`) layak mendapat perhatian khusus karena secara fundamental mengubah model mental yang dibawa banyak administrator dari sistem yang lebih lama.

Masalah yang diselesaikannya: Secara historis, `/bin`, `/sbin`, `/lib`, dan `/lib64` ada sebagai direktori independen pada filesystem root, terpisah dari `/usr`. Ini mengharuskan initramfs untuk berisi kumpulan alat minimal guna memasang `/usr` sebelum sistem penuh dapat diinisialisasi. Seiring initramfs menjadi universal dan `/usr` mulai diperlakukan sebagai volume read-only yang berpotensi dipasang melalui jaringan atau dikelola snapshot, pemisahan tersebut menjadi hambatan untuk pembaruan atomik dan penerapan berbasis image.

Apa yang berubah: Pada sistem yang telah digabungkan, direktori tingkat root menjadi symlink:

“`

/bin -> usr/bin

/sbin -> usr/sbin

/lib -> usr/lib

/lib64 -> usr/lib64

“`

Distribusi yang telah menyelesaikan UsrMerge:

• Fedora (sejak Fedora 17, 2012)
• Arch Linux (sejak 2013)
• Debian (sejak Debian 12 Bookworm, 2023)
• Ubuntu (sejak Ubuntu 21.10)
• RHEL/CentOS (sejak RHEL 7)

Dampak praktis: Skrip yang mengkodekan keras `/bin/bash` tetap berfungsi karena `/bin` adalah symlink ke `/usr/bin`. Namun, skrip yang mencoba menentukan apakah suatu jalur “esensial” dengan memeriksa apakah dimulai dengan `/bin` daripada `/usr/bin` akan menghasilkan hasil yang salah. Perbarui logika semacam itu dalam alat otomasi Anda.

Izin Direktori Biner dan Penguatan Keamanan

Memahami direktori biner tidak dapat dipisahkan dari memahami implikasi keamanannya. Beberapa langkah penguatan berlaku langsung pada jalur-jalur ini.

Baseline izin yang direkomendasikan:

Biner SUID/SGID: Beberapa biner di `/usr/bin` dan `/usr/sbin` membawa bit SUID, memungkinkan mereka untuk dieksekusi dengan hak istimewa tinggi terlepas dari siapa yang memanggilnya. Contohnya termasuk `passwd`, `sudo`, `su`, dan `ping`. Audit ini secara berkala:

“`bash

find /usr/bin /usr/sbin /bin /sbin -perm /4000 -o -perm /2000 2>/dev/null

“`

Flag immutable: Pada sistem dengan keamanan tinggi, pertimbangkan untuk menerapkan `chattr +i` pada biner kritis atau memasang `/usr` sebagai read-only. Ini mencegah modifikasi runtime oleh malware atau proses yang dikompromikan, meskipun memerlukan remount sebagai read-write untuk pembaruan paket yang sah.

Opsi mount `noexec`: Memasang `/tmp` dan `/var/tmp` dengan `noexec` mencegah biner yang ditempatkan di sana dieksekusi secara langsung — teknik umum dalam serangan web shell. Ini tidak memengaruhi direktori biner itu sendiri tetapi merupakan langkah penguatan komplementer yang relevan untuk server mana pun yang menjalankan aplikasi web, termasuk yang menggunakan lingkungan Shared Web Hosting.

Variabel Lingkungan PATH dan Urutan Resolusi Biner

Variabel `PATH` menentukan urutan di mana shell mencari direktori untuk executable. Memahami urutan ini sangat penting untuk men-debug kesalahan “command not found” dan untuk pembayangan biner yang disengaja.

PATH root umum pada sistem Debian/Ubuntu:

“`

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

“`

PATH pengguna tanpa hak istimewa umum:

“`

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

“`

Pengamatan utama:

• `/usr/local/bin` mendahului `/usr/bin`, sehingga biner yang diinstal secara lokal membayangi yang dikelola paket.
• `/sbin` dan `/usr/sbin` tidak ada dalam PATH pengguna tanpa hak istimewa default pada beberapa distribusi, itulah mengapa menjalankan `ifconfig` sebagai pengguna non-root mungkin gagal dengan “command not found” meskipun biner tersebut ada.
• Ketika sebuah layanan berjalan di bawah akun pengguna non-root (misalnya, pengguna aplikasi web), PATH-nya mungkin bahkan lebih terbatas. Selalu gunakan jalur absolut dalam file unit layanan dan cron job.

Men-debug masalah PATH:

“`bash

Find all instances of a binary across PATH directories:

which -a python3

Show full PATH resolution including aliases and functions:

type -a python3

Check the effective PATH for a specific service:

systemctl show myservice | grep -i environment

“`

Matriks Keputusan Praktis: Di Mana Menginstal Biner

Saat menerapkan perangkat lunak pada server Linux — baik itu alat yang dikompilasi, biner yang diunduh, atau skrip kustom — gunakan kerangka keputusan ini:

Apakah dikelola oleh manajer paket sistem?

• Ya: Manajer paket menempatkannya di `/usr/bin` atau `/usr/sbin` secara otomatis. Jangan pindahkan.

Apakah biner atau skrip tunggal yang diinstal secara manual, ditujukan untuk semua pengguna?

• Alat yang menghadap pengguna: `/usr/local/bin`
• Alat root/admin: `/usr/local/sbin`

Apakah bundel aplikasi mandiri dengan dependensinya sendiri?

• Gunakan `/opt/<vendor>/<package>/` dan buat symlink biner utama ke `/usr/local/bin`

Apakah alat sementara atau khusus pengguna?

• Tempatkan di `~/bin` (buat jika belum ada) dan tambahkan `~/bin` ke `PATH` pribadi Anda di `~/.bashrc` atau `~/.profile`

Apakah pustaka bersama untuk aplikasi yang dikompilasi secara manual?

• Instal ke `/usr/local/lib`, lalu jalankan `ldconfig`

Kerangka ini mencegah bentuk paling umum dari entropi filesystem pada server yang telah lama berjalan: biner yang tersebar di berbagai lokasi sembarangan, tidak terlihat oleh manajer paket, dan dilupakan oleh administrator yang menginstalnya.

Daftar Periksa Poin Teknis Utama

• Verifikasi status UsrMerge pada sistem Anda dengan `ls -la /bin /sbin /lib`. Jika merupakan symlink, `/bin` dan `/usr/bin` adalah namespace yang identik.
• Jangan pernah menempatkan file langsung di `/usr/bin` atau `/usr/sbin` — pembaruan paket akan menimpanya secara diam-diam.
• Selalu jalankan `ldconfig` setelah menginstal pustaka bersama ke `/usr/local/lib` atau jalur non-standar mana pun.
• Gunakan jalur absolut dalam cron job, file unit systemd, dan skrip init — jangan pernah mengandalkan `PATH` yang diatur dengan benar dalam konteks non-interaktif.
• Audit biner SUID/SGID setiap kuartal pada server produksi: `find /usr /bin /sbin -perm /6000 -type f`
• Dokumentasikan setiap biner yang diinstal ke `/usr/local/` dan `/opt/` dengan versi, URL sumber, dan tanggal instalasi dalam sistem manajemen konfigurasi atau setidaknya changelog lokal.
• Pada sistem merged-usr, perbarui otomasi apa pun yang membedakan biner “esensial” berdasarkan awalan jalur — perbedaan tersebut kini murni semantik.
• Saat menerapkan aplikasi pada VPS Control Panels atau lingkungan hosting terkelola, konfirmasikan apakah panel kontrol memodifikasi `PATH` atau menginstal versi binernya sendiri di bawah `/opt` atau `/usr/local`, karena ini dapat menyebabkan konflik versi dengan alat sistem.
• Untuk alat terkait SSL (`openssl`, `certbot`), konfirmasikan versi biner mana yang sedang dipanggil — versi yang diinstal secara manual yang sudah usang di `/usr/local/bin` akan membayangi versi yang dikelola paket dan mungkin membawa kerentanan yang belum ditambal. Padukan ini dengan manajemen SSL Certificates yang tepat untuk memastikan rantai alat kriptografi Anda mutakhir dari ujung ke ujung.

Pertanyaan yang Sering Diajukan

Apa perbedaan antara `/bin` dan `/usr/bin` pada Linux modern?

Pada distribusi modern yang telah menyelesaikan UsrMerge, tidak ada perbedaan fungsional — `/bin` adalah symbolic link ke `/usr/bin`. Secara historis, `/bin` hanya berisi biner yang diperlukan sebelum `/usr` dapat dipasang, sementara `/usr/bin` menyimpan semua yang lain. Perbedaan ini kini bersifat semantik pada sistem yang telah digabungkan tetapi tetap signifikan secara arsitektur pada instalasi Linux yang lebih lama atau tertanam.

Mengapa menempatkan biner di `/usr/local/bin` menggantikan biner yang sama di `/usr/bin`?

Karena `/usr/local/bin` muncul lebih awal dalam `PATH` default daripada `/usr/bin`. Shell menyelesaikan perintah dengan mencari direktori `PATH` dari kiri ke kanan dan mengeksekusi kecocokan pertama yang ditemukan. Urutan ini disengaja — memungkinkan administrator untuk menerapkan penggantian lokal tanpa memodifikasi file yang dikelola paket.

Apa yang terjadi jika saya lupa menjalankan `ldconfig` setelah menginstal pustaka bersama?

Cache dynamic linker (`/etc/ld.so.cache`) tidak akan menyertakan pustaka baru, dan biner mana pun yang bergantung padanya akan gagal saat runtime dengan kesalahan seperti `error while loading shared libraries: libfoo.so.1: cannot open shared object file: No such file or directory`. Menjalankan `sudo ldconfig` membangun ulang cache dan segera menyelesaikan masalah.

Apakah aman menginstal perangkat lunak langsung ke `/usr/bin` daripada `/usr/local/bin`?

Tidak. File di `/usr/bin` dimiliki dan dilacak oleh manajer paket. Pembaruan paket atau pembaruan sistem di masa mendatang dapat menimpa, memindahkan, atau menghapus file mana pun di direktori tersebut tanpa peringatan. Selalu gunakan `/usr/local/bin` untuk biner yang diinstal secara manual guna menjaga pemisahan yang bersih antara perangkat lunak yang dikelola paket dan yang dikelola administrator.

Bagaimana cara menemukan direktori mana yang sedang dieksekusi oleh sebuah perintah?

Gunakan `which <command>` untuk pencarian cepat kecocokan pertama dalam `PATH`, atau `type -a <command>` untuk mencantumkan semua kecocokan termasuk built-in shell, alias, dan setiap instans di semua direktori `PATH`. Untuk jawaban definitif termasuk resolusi symlink, gunakan `readlink -f $(which <command>)`.