Belajar Fzf - Remote Development & SSH Workflow

#Pendahuluan

Di episode 12 kalian belajar menaruh fzf di popup tmux dan Zellij — membiarkan antarmuka pencarian melayang di atas pekerjaan, tidak menimpa layar. Sekarang mari kita seret pertanyaan berikutnya: apa jadinya jika pekerjaan itu bukan di mesin kalian, melainkan di server? Seorang engineer infrastruktur jarang bekerja hanya di satu mesin; ia bergantian masuk ke app server, database host, dan jump box hampir sepanjang hari.

Episode ini membahas cara memakai fzf di dunia remote: menjalankan fzf langsung di dalam sesi SSH untuk mencari file, menelusuri history, dan memilih proses server; memakai pola fzf + xargs untuk operasi batch yang aman; menggabungkan hasil pencarian lokal dengan tindakan remote dalam workflow hibrida; serta mengelola puluhan host dengan completion berbasis fzf.

Prinsip pertama yang harus kalian pegang: fzf tidak peduli dari mana daftar item berasal. Selama ia menerima baris-baris teks di stdin dan mencetak pilihan di stdout, sumbernya bisa berupa mesin lokal, mesin remote, atau bahkan file cache. Itulah kunci seluruh episode ini.

#Kenapa fzf Juga Berlaku di Remote

Banyak yang mengira fzf adalah alat lokal, padahal ia hanyalah proses terminal biasa. Selama SSH menyediakan TTY (yang selalu ia lakukan untuk sesi interaktif), fzf berjalan dengan baik di ujung sana. Bedanya bukan pada fzf-nya, melainkan pada tempat perintah preview dieksekusi: jika fzf berjalan di server, preview-nya membaca file dan proses server; jika fzf berjalan di lokal, preview harus tahu cara menjangkau server.

Mental modelnya seperti ini: jalankan fzf sedekat mungkin dengan data yang ingin kalian lihat. Mau memilih proses di server? Jalankan fzf di server agar preview-nya bisa langsung memanggil ps. Mau memilih baris log yang sudah kalian tarik ke lokal? Jalankan fzf di lokal agar preview-nya cepat tanpa round-trip jaringan.

#Mencari File di Server via SSH

Kasus paling sederhana: mencari file di server dengan fd atau find, lalu memilihnya interaktif. Karena fzf berjalan di server, semuanya lokal bagi server — termasuk preview:

Pilih file di server

ssh deploy@app01 'fd . /srv -t f | fzf --preview "head -n 50 {}"'

fzf berjalan di server sehingga preview bisa langsung membaca isi file

Perhatikan bahwa tanda kutipnya bersarang: kutip tunggal untuk keseluruhan perintah remote agar shell lokal tidak ikut memproses, lalu kutip ganda untuk perintah preview. Jika fzf belum terpasang di server, cukup sekali apt install fzf atau jalankan installer resminya — sama seperti di mesin lokal.

Tip

Mencari dengan find di direktori besar bisa terasa lambat karena daftar dibangun utuh sebelum fzf terbuka. Untuk server yang sudah punya fd, hasilnya jauh lebih cepat karena fd melakukan parallel traversal. Di server tanpa fd, praktik umum adalah membatasi kedalaman (-maxdepth 3) atau memakai find bersamaan dengan filter jenis file.

#Menelusuri History dan Memilih Proses Remote

Dua tugas operasional paling umum di server — menelusuri command history dan memilih proses — juga menjadi fzf yang sempurna. History yang di-sort menghilangkan duplikat sehingga kalian tidak mengarungi baris yang sama berulang kali:

Telusuri history di server

ssh deploy@app01 'cat ~/.bash_history | sort -u | fzf --height 40% --layout reverse'

sort -u membersihkan duplikat sebelum masuk ke fzf

Memilih proses jauh lebih kuat ketika fzf berjalan di server, karena preview-nya memakai ps di mesin yang sama. Di sini placeholder {1} mengambil field pertama — kolom PID:

Pilih proses dengan preview detail

ssh deploy@app01 'ps -eo pid,user,comm | fzf --header "Pilih proses" --preview "ps -fp {1}"'

Preview perintah ps -fp untuk PID yang sedang disorot

Ini analog dengan top interaktif, tetapi dengan kekuatan fuzzy: ketik nginx dan langsung melompat ke proses nginx, tanpa menekan tombol pencarian sekali pun.

#Batch Operation: fzf + xargs

Kini tiba pola paling berharga: memilih banyak item lalu mengeksekusi satu perintah pada semuanya. Kombinasi fzf --multi + xargs adalah tulang punggung operasi batch. Contoh berikut memilih beberapa container Docker di server lalu me-restart semuanya:

Restart container terpilih

ssh deploy@app01 'docker ps --format "{{.Names}}"' \
    | fzf --multi --height 40% \
    | xargs -I{} ssh deploy@app01 'docker restart {}'

--multi menandai banyak container; xargs mengeksekusi restart satu per satu

xargs -I{} mengganti {} pada perintah dengan satu item pilihan — jadi perintah remote yang dijalankan mirip ssh deploy@app01 'docker restart web-api'. Pola yang sama berlaku untuk menyalakan ulang service systemd, menghapus file log lama, atau mengambil beberapa file dengan scp.

Warning

xargs memecah argumen berdasarkan spasi dan newline secara default. Jika daftar item kalian adalah nama file yang bisa mengandung spasi, gunakan pembatas null: fzf --multi --print0 | xargs -0 -I{} ssh host "perintah {}". Prinsip ini persis seperti yang kita bahas soal --read0 dan --print0 di episode 6 — di sini taruhannya lebih tinggi karena kesalahan parsing berujung pada perintah yang dieksekusi di server.

#Workflow Hibrida: Daftar Lokal, Tindakan Remote

Tidak semua langkah harus berjalan di satu tempat. Pola hibrida yang sering dipakai: daftar item dibangun dan dipilih di lokal, tindakan dieksekusi di remote. Ini menghemat latensi karena fzf tidak perlu menunggu jaringan setiap kali query berubah, dan memberi preview lokal yang responsif.

Contohnya, tarik daftar log ke file lokal sekali, lalu pilih dengan preview yang menjangkau server hanya untuk baris yang sedang disorot:

Daftar remote, preview on-demand

ssh deploy@app01 'find /var/log -name "*.log" -mtime -7' > /tmp/app01-logs.txt
cat /tmp/app01-logs.txt | fzf --preview 'ssh deploy@app01 "tail -n 30 {}"'

Daftar di-cache lokal; hanya preview yang memanggil SSH

Perhatikan trade-off-nya: membangun daftar sekali lewat find di server itu murah, tetapi preview yang memanggil ssh untuk setiap perpindahan kursor bisa terasa lambat. Untuk daftar besar, batasi perintah preview dengan ssh -o ConnectTimeout=2 atau pindahkan ke pola "jalankan fzf di server" seperti contoh pertama.

Important

Aturan praktis memilih lokasi eksekusi: jalankan fzf di sisi tempat data paling sering diakses. Data berubah cepat dan banyak di server? Fzf di server. Data adalah snapshot yang sudah ditarik ke lokal? Fzf di lokal. Menaruh fzf di sisi yang salah adalah penyebab paling umum "kenapa fzf remote terasa lambat".

#Mengelola Banyak Host: SSH Completion

Semakin banyak server, semakin lama kalian mengetik nama host. Daftar host dari ~/.ssh/config adalah kandidat sempurna untuk fzf: dibangun dari satu file, terstruktur, dan dipakai setiap hari. Fungsi sederhana berikut menggantikan hafalan nama host dengan dialog fuzzy:

Fungsi SSH completion dengan fzf

sshp() {
  local host
  host=$(grep '^Host ' ~/.ssh/config | awk '{print $2}' \
    | grep -v '\*' | fzf --prompt 'SSH host> ' --tmux center,50%)
  [ -n "$host" ] && ssh "$host"
}

Pilih host dari konfigurasi, lalu ssh ke sana dalam satu gerakan

Ketik sshp, lalu filter nama host — cukup ketik prod untuk menyisakan semua host produksi. Kombinasi dengan --tmux dari episode 12 membuat dialog ini melayang di atas apa pun yang sedang kalian kerjakan, dan Enter langsung menempel ke server tujuan.

#Kesalahan Umum

Kesalahan	Gejala	Solusi
Menjalankan fzf di lokal tapi preview membutuhkan file server	Preview kosong atau error	Jalankan fzf di server, atau panggil ssh di dalam preview
`xargs` tanpa `-0` pada daftar ber-spasi	Argumen terpecah, perintah keliru	`fzf --multi --print0 \| xargs -0 -I{} ssh host "cmd {}"`
Build daftar remote setiap kali preview berganti	Terasa lambat karena round-trip jaringan	Cache daftar ke file lokal, batasi preview on-demand
Nama host diketik manual	Salah ketik, SSH ke host yang keliru	Gunakan completion fzf dari `~/.ssh/config`
Lupa bahwa `{}` di preview dieksekusi oleh shell remote	Perintah tidak berjalan seperti diduga	Uji preview pada satu item dulu sebelum dipakai luas

#Penutup

Pada episode 13 ini kalian menuntaskan satu pertanyaan penting: fzf tidak mengenal batas mesin. Kalian bisa menjalankannya langsung di server lewat SSH untuk mencari file, menelusuri history, dan memilih proses dengan preview yang membaca server secara langsung; memakai pola fzf --multi + xargs -I{} untuk operasi batch; menggabungkan daftar lokal dengan tindakan remote dalam workflow hibrida; serta mengelola banyak host dengan completion fzf dari ~/.ssh/config.

Prinsip yang harus dibawa pulang: letakkan fzf di sisi tempat data paling sering diakses, dan perlakukan item sebagai data yang tidak pernah bisa dipercaya oleh shell.

Kalimat terakhir itu bukan basa-basi — ia justru menjadi pintu masuk episode berikutnya. Semakin sering fzf mengeksekusi perintah untuk kalian (preview, execute, become), semakin besar permukaan tempat sesuatu yang berniat buruk bisa masuk. Di episode 14 kita membahas security & best practices: risiko command injection lewat --preview dan --bind, cara menulis perintah fzf yang aman, serta menjaga privasi — supaya alat yang mempercepat kerja kalian tidak berbalik menjadi pintu masuk masalah.