Mengapa input teks di terminal itu rumit

 (jvns.ca)
1 poin oleh GN⁺ 2024-07-09 | 1 komentar | Bagikan ke WhatsApp
  • Memperbaiki teks di command line tampak seperti fitur dasar, tetapi pemrosesan input berbeda-beda di tiap program sehingga tombol yang sama bisa berperilaku sangat berbeda
  • Pengalaman input terminal secara umum terbagi menjadi empat alur: tanpa sistem input, GNU readline, pustaka alternatif seperti libedit, dan sistem input buatan sendiri
  • Pada alat sederhana seperti cat, nc, dan dash, tombol panah bisa tercetak seperti ^[[D, tetapi Ctrl+W, Ctrl+U, Ctrl+C, dan Ctrl+Z yang disediakan terminal tetap bisa digunakan
  • Alat berbasis readline seperti bash, psql, irb, dan python3 menyediakan histori, tombol panah, pencarian Ctrl+R, serta perpindahan Ctrl+A/Ctrl+E; pengalaman serupa bisa ditambahkan dengan rlwrap
  • Dengan mengenali sistem input yang sedang dipakai, Anda bisa cepat menilai mengapa tombol panah atau Ctrl+R terlihat berbeda, lalu bila perlu memilih untuk memeriksa dokumentasi atau memakai jalan pintas seperti rlwrap

Pengalaman input yang berbeda di tiap program

  • Cara memasukkan dan mengedit teks di terminal sangat berbeda antarprogram
  • Tipe umumnya terbagi sebagai berikut
    • cat, nc, git commit --interactive, dan sejenisnya tidak mendukung tombol panah sehingga string seperti ^[[D^[[D^[[C^[[C^ bisa terlihat
    • irb, python3 di Linux, dan sejenisnya menyediakan fitur pengeditan dasar seperti histori dan tombol panah melalui pustaka readline
    • Ada juga kasus seperti /usr/bin/python3 di Mac, di mana tombol panah berfungsi tetapi pencarian mundur Ctrl+left atau Ctrl+R tidak didukung
    • fish, ipython3, micro, vim, dan sejenisnya menggunakan sistem input sendiri

Mode 1: keadaan dasar tanpa sistem input

  • Jika sebuah program hanya menerima teks lewat pemanggilan seperti fgets() dan tidak menyediakan fitur pengeditan terpisah, tombol panah bisa dicetak sebagai escape sequence, bukan perintah edit
  • Misalnya, saat menekan panah kiri di dash, ^[[D akan tercetak di terminal seperti berikut
$ ls l-^[[D^[[D^[[D
  • Namun, fitur kontrol bawaan yang disediakan terminal tetap ada
    • Input teks
    • Backspace
    • Ctrl+W: menghapus kata sebelumnya
    • Ctrl+U: menghapus seluruh baris
    • Ctrl+C: menginterupsi proses
    • Ctrl+Z: menangguhkan proses
  • Bahkan di lingkungan seperti ini, memakai Ctrl+W memungkinkan Anda menghapus per kata tanpa menekan backspace berkali-kali
  • Kode kontrol yang didukung terminal bisa diperiksa dengan stty -a

Mode 2: alat yang menggunakan readline

  • readline adalah pustaka GNU yang membuat input teks lebih nyaman, dan digunakan di banyak alat interaktif
  • Pintasan readline yang sering dipakai adalah sebagai berikut
    • Ctrl+E atau End: pindah ke akhir baris
    • Ctrl+A atau Home: pindah ke awal baris
    • Ctrl+left/right arrow: pindah maju/mundur per kata
    • Panah atas: pindah ke perintah sebelumnya
    • Ctrl+R: mencari histori
  • Ctrl+W dan Ctrl+U dari mode dasar juga bisa digunakan, tetapi di readline Ctrl+U menghapus dari kursor hingga awal baris, bukan seluruh baris
  • Pencarian histori Ctrl+R di bash adalah fitur yang disediakan readline
  • psql, irb, python3, dan lainnya juga merupakan contoh program yang menggunakan readline
  • Daftar lengkap perintah pengeditan readline bisa dilihat di manual readline

Menambahkan rlwrap ke alat tanpa readline

  • Program yang tidak mendukung readline seperti nc pun bisa digunakan seperti program dengan dukungan readline jika dijalankan sebagai rlwrap nc
  • rlwrap dapat sangat meningkatkan kegunaan alat yang tidak memiliki readline
  • Autocomplete kustom juga bisa diatur, tetapi ini bukan sesuatu yang pernah benar-benar dicoba

Mengapa alat tidak menggunakan readline

  • Ada beberapa alasan mengapa sebagian alat tidak menggunakan readline
    • Program yang sangat sederhana seperti cat dan nc mungkin tidak ingin menambahkan dependensi yang relatif besar
    • readline bukan LGPL melainkan berlisensi GPL, sehingga bisa tidak cocok dengan lisensi program
    • Jika hanya sebagian program bersifat interaktif dan inputnya mendekati satu karakter seperti y atau n, dukungan readline bisa menjadi prioritas rendah
  • git memiliki fitur interaktif seperti git add -p, tetapi ketika membutuhkan input panjang yang bermakna, biasanya ia menjalankan editor teks
  • idris2 tidak menggunakan readline demi meminimalkan dependensi, dan menyarankan penggunaan rlwrap jika membutuhkan fitur interaktif yang lebih baik

Cara memeriksa apakah sedang menggunakan readline

  • Cara paling sederhana adalah mencoba menekan Ctrl+R
  • Jika prompt berikut terlihat, kemungkinan besar Anda sedang menggunakan readline
(reverse-i-search)`':
  • Pustaka lain juga bisa memakai istilah yang sama sehingga ini bukan cara identifikasi yang pasti, tetapi tidak diketahui ada sistem lain yang memakai ungkapan reverse-i-search untuk pencarian histori

Pintasan readline dan Emacs

  • Pintasan Ctrl+A untuk ke awal baris dan Ctrl+E untuk ke akhir baris dapat dianggap berasal dari Emacs
  • Di Emacs pun, Ctrl+A dan Ctrl+E berperilaku sama seperti di readline
  • Sebaliknya, Ctrl+W dan Ctrl+U tidak berperilaku sama di Emacs dan terminal
  • Riwayat proyek readline bisa dibaca lebih lanjut di Sejarah proyek Readline

Mode 3: pustaka input alternatif seperti libedit

  • /usr/bin/python3 di Mac berada dalam kondisi antara yang hanya mendukung sebagian fitur readline
  • Misalnya, saat menekan Ctrl+left arrow, yang tercetak bisa jadi ;5D, bukan perpindahan kata
$ python3
>>> importt subprocess;5D
  • Pada instalasi Python bawaan Mac OS, modul Python readline sebenarnya berbasis libedit
  • Ini diduga karena readline berlisensi GPL
  • Anda bisa memeriksa apakah Python tersebut memakai libedit dengan perintah berikut
$ python3 -c "import readline; print(readline.__doc__)"
Importing this module enables command line editing using libedit readline.
  • Python yang dipasang melalui Linux atau Homebrew umumnya menggunakan readline
  • Python 3.13 direncanakan menghapus dependensi readline dan menggunakan pustaka sendiri, sehingga ke depan pernyataan “Python menggunakan readline” mungkin tidak selalu benar

Mode 4: sistem input buatan sendiri

  • Sebagian program menggunakan sistem pengeditan teks sendiri, dan kadang menyediakan fitur yang lebih beragam daripada readline
  • Contoh yang menggunakan sistem input sendiri adalah sebagai berikut
    • Sebagian besar editor teks terminal seperti nano, micro, vim, dan emacs
    • Shell seperti fish
    • Editor baris zsh, zle
    • REPL seperti ipython
    • Alat seperti atuin
  • Dalam sistem seperti ini, Anda bisa melihat fitur berikut
    • Autocomplete yang lebih disesuaikan dengan alat
    • Manajemen histori yang lebih baik, termasuk syntax highlighting
    • Lebih banyak pintasan keyboard

Sistem input buatan sendiri yang terinspirasi readline

  • Atuin adalah alat pencarian histori shell, dan meski implementasi inputnya dibuat sendiri, caranya terinspirasi dari readline
  • Atuin memanfaatkan fakta bahwa pengguna sudah terbiasa dengan key binding readline, sehingga key binding tersebut tetap berfungsi tanpa memakai readline secara langsung
  • prompt_toolkit yang dipakai IPython juga mendukung berbagai opsi, termasuk key binding gaya vi
  • Nilai bawaan prompt_toolkit adalah dukungan key binding gaya readline
  • Ini mirip dengan banyak program yang mendukung key binding vim dasar: j untuk turun dan k untuk naik
  • Misalnya Fastmail mendukung j dan k, meski sebagian besar pintasannya tidak terlalu terkait dengan vim
  • Sistem input buatan sendiri yang terinspirasi readline bisa saja tidak sepenuhnya kompatibel dengan readline, tetapi bagi pengguna yang hanya memakai beberapa pintasan dasar, ini mungkin bukan masalah besar
  • Sistem buatan sendiri seperti ini biasanya bisa memiliki autocomplete yang lebih baik daripada jika hanya memakai readline

Shell yang mendukung mode vi

  • bash, zsh, dan fish semuanya mendukung mode vi untuk input teks
  • Dalam survei tidak ilmiah di Mastodon, 12% menjawab bahwa mereka menggunakan mode vi
  • readline sendiri juga memiliki mode vi, dan dukungan mode vi di bash bekerja melaluinya
  • Banyak program lain yang menggunakan readline juga bisa memiliki mode vi

Alur mendiagnosis keadaan input

  • Mengetahui sistem input apa yang dipakai membuat perilaku command line lebih mudah diprediksi
  • Pada prompt input, Anda bisa menilainya dengan urutan berikut
    • Jika tombol panah tidak berfungsi, kemungkinan besar tidak ada sistem input; meski begitu, Ctrl+W dan Ctrl+U tetap bisa digunakan, dan jika perlu Anda bisa menambahkan rlwrap
    • Jika Ctrl+R menampilkan reverse-i-search, kemungkinan besar itu readline, dan Anda bisa memakai pintasan readline yang familier serta fitur histori dasar
    • Jika Ctrl+R melakukan hal lain, kemungkinan besar itu pustaka input buatan sendiri; biasanya perilakunya bisa mirip readline, dan bila perlu Anda bisa memeriksa dokumentasinya
  • Masih ada kompleksitas terkait input yang tidak dibahas di sini
    • Masalah terkait ssh dan tmux
    • Variabel lingkungan TERM
    • Perbedaan dukungan salin-tempel di tiap terminal seperti GNOME Terminal, iTerm, dan xterm
    • Unicode
    • Berbagai masalah input lainnya

Bacaan terkait

1 komentar

 
GN⁺ 2024-07-09
Komentar Hacker News

  • Tulisan Julia selalu bagus. Tambahan yang belum disebut, memakai stty di dalam skrip shell bisa mengubah banyak perilaku terminal, termasuk cara input diproses
    Eksperimen yang dulu pernah saya coba dengan sh dan stty: https://gist.github.com/alganet/63f1dbc97b8fd35f7bb14ec30f79...
    Di terminal yang kompatibel VT100 (mintty, xterm, Terminal.app, vscode, dll.), sebagian besar kombinasi tombol dan bahkan gestur mouse (tekan/seret/lepas) bisa ditangkap dan diinterpretasikan dari dalam shell
    Demo untuk menjalankannya adalah bash -c "$(curl -L https://git.io/fjToH)"; coba tekan tombol atau gerakkan mouse. Keluar dengan Ctrl+W. zsh dan ksh juga didukung, tetapi dash dan shell lain yang tidak punya read -rn1 tidak didukung
    Selain itu, jika program interaktif dipipe ke cat -v seperti vi | cat -v, kita bisa melihat escape VT100 yang dipakai program tersebut, dan saya banyak belajar dengan mengamati bagaimana vi melakukannya

    • Jika setelah menjalankan perintah terminal jadi rusak, tidak menampilkan output, atau muncul karakter aneh, mungkin perintah itu tidak melakukan pembersihan tty dengan benar. Tidak perlu mematikan terminal; cukup ketik stty sane untuk memulihkannya
    • Saat membaca bagian awal The UNIX Programming Environment karya Kernighan, saya terpikir mencoba cara aneh seperti ini dengan semangat yang mirip untuk menjelajahi perilaku I/O terminal
      Buka 3 terminal lalu jalankan 1) man ascii, 2) nc -lvp 9001 | xxd -c1, 3) stty raw -echo; nc -nv 127.0.0.1 9001; setelah itu, di terminal nomor 3, coba reproduksi seluruh kolom “Hex” pada manpage secara berurutan
      Dari situ bisa diamati bahwa beberapa nilai dapat dibuat dengan lebih dari satu cara, dan sebagian tombol lain mengirim payload multi-byte
    • Artikel tentang membuat editor teks terminal ini juga membantu untuk memahami stty dan mode mentah: https://viewsourcecode.org/snaptoken/kilo/, https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode...
      Parameter dan simbol stty yang tampak seperti sihir itu berasal dari urutan kontrol yang didefinisikan sejak lama. Standar samar dari era 1970-an seperti ECMA-48 penuh dengan istilah ganjil yang sekarang hampir tak lagi dipakai
      Misalnya, Select Graphic Rendition (SGR) kira-kira seperti tag HTML versi 1970-an, dan untuk mengatur warna foreground dipakai bentuk seperti ESC[38;2;R;G;BmTextESC[0m. ESC[ adalah CSI, m adalah SGR, 38 berarti warna foreground, 2 berarti ruang warna RGB, dan 0 berarti reset gaya
      Karena parameternya datang sebelum perintah, strukturnya terasa agak terbalik. Seperti browser, terminal juga berbeda-beda dalam cakupan dan cara implementasinya, dulu maupun sekarang. Warna didukung cukup baik, tapi fitur lain tidak selalu demikian. Misalnya SGR<7> disebut mode “negative image”, namun standar tidak menjelaskannya dengan rinci, sehingga ada terminal yang menampilkan warna terbalik, ada juga yang menanganinya dengan cara lain, dan ini masih menimbulkan masalah sampai sekarang
    • Sebelum langsung mengalirkan kode dari internet ke bash, selalu periksa dulu. Demo ini sepertinya sempat merusak konfigurasi non-standar saya dengan cara aneh, dan saya tidak berniat mendokumentasikannya dengan rinci
    • Di Sonoma muncul pesan “The invoked shell does not support interactive features”

  • Lebih dari 20 tahun lalu saya membuat state machine di atas readline agar bisa dipakai sebagai editor multi-baris sungguhan, bukan sekadar satu baris yang terlipat, melainkan bisa bergerak naik-turun antarbaris
    Video: https://github.com/colmmacc/jot/raw/master/jot-demo.mp4
    Repositori CVS klien IM terminal Unix yang memuat fitur ini: https://c-hey.redbrick.dcu.ie/src/c-hey_cvs_latest/
    Saat berpindah ke atas dan bawah antarbaris, ia melacak kursor lalu menggambar ulang, dan ketika ukuran terminal berubah, ia memantau SIGWINCH lalu menggambar ulang lagi. Saya ingin menulis ulang ini dalam Rust dan merilisnya sebagai pustaka kecil, tetapi tidak pernah punya waktu. Saya selalu heran kenapa hampir tidak ada orang lain yang melakukan hal serupa

    • Cukup keren, jadi saya ingin mengambil idenya. Untuk kasus tertentu, sepertinya ini bisa diimplementasikan di zsh hanya dengan beberapa baris
      Setelah autoload -Uz zed, gunakan zed untuk mengedit file sementara lalu kirimkan ke git commit -F, maka kita bisa memulai editor inline dengan semua kemampuan ZLE. Simpan dengan C-x C-w lalu commit, atau batalkan dengan C-c
      Keunggulan implementasi dasar ini adalah zed merupakan widget ZLE baru, jadi keymap bisa dikendalikan sepenuhnya. Mode emacs maupun vi langsung berfungsi, dan masih bisa dikustomisasi lebih lanjut
      Jika menulis widget ZLE sendiri, itu bahkan bisa dipanggil langsung dari editor baris tanpa perlu membungkus perintah seperti contoh di atas
      https://github.com/zsh-users/zsh/blob/master/Functions/Misc/...
    • Sebelum menonton videonya, saya tidak sadar seberapa jauh pengalaman mengedit seperti ini bisa lebih baik, dan saya setuju dengan keuntungannya karena tidak perlu pindah konteks seperti pada mode interaktif git commit. Efek seperti “mesin tik inline” juga keren
    • Jendela teks rio saat dalam mode hold juga tampak mirip. Hanya saja desainnya jauh lebih sederhana dan dukungan mousenya lebih baik: https://p9f.org/magic/man2html/1/rio
    • Saya penasaran apakah versi program saat ini sudah stabil

  • Hal-hal yang tidak dibahas dalam tulisan ini antara lain karakter lebar, masalah input tombol yang sama bisa direpresentasikan sebagai urutan escape ANSI yang berbeda karena perbedaan mode keyboard, perbedaan status TTY seperti local echo, serta fakta bahwa system call untuk mengubah status TTY sedikit berbeda di tiap sistem operasi
    Dukungan emulasi terminal juga berbeda-beda. Zaman sekarang umumnya meniru xterm, tetapi bahkan di dalam itu pun tidak ada yang benar-benar menargetkan kompatibilitas 100%
    Bahkan untuk cara memeriksa fitur yang disediakan terminal pun belum ada kesepakatan. Ada yang mengirim urutan escape ANSI lalu menunggu respons, ada yang melihat $TERM, dan ada terminal yang mengaku sebagai xterm sambil mengabaikan urutan fitur VT dan justru menetapkan variabel lingkungan lain. Sejujurnya ini lebih berantakan daripada string user-agent
    Semua ini masih dengan asumsi sistem POSIX; kalau Windows ikut dicampur, jadinya dua kali lebih menarik

  • Jika di bash Anda mengatur $EDITOR ke editor favorit, Anda bisa memakai Ctrl-X Ctrl-E untuk mengirim baris saat ini ke $EDITOR. Setelah mengedit perintah, simpan dan keluar, maka perintah itu akan dijalankan

    • Jika Anda veteran Unix lama yang memakai mode vi di ksh, cukup tekan v
    • Perintah bawaan fc juga melakukan hal yang sama. Cukup ketik fc tanpa rangkaian tombol Ctrl
      Anda juga bisa membuka perintah sebelumnya dengan editor tertentu alih-alih $EDITOR bawaan. Misalnya saat EDITOR=vi, jika ingin mengedit perintah terakhir dengan ed, gunakan fc -e ed
      Di mode vi, ada juga cara cepat membuat skrip shell dari riwayat perintah. Jika perintah yang diinginkan adalah yang ke-15 di riwayat, Anda bisa melakukan fc 15, lalu w1.sh, %d, wq
    • Di fish, itu Alt-e
    • Saya suka shortcut seperti ini, tetapi justru tidak pernah ingat saat membutuhkannya
    • Di Neovim saya memakai EDITOR=nvim bersama copilot.vim dan memakainya seperti pelengkapan otomatis shell berbasis AI. Cukup bagus
      Lihat di sini: https://twitter.com/arjie/status/1575201117595926530?s=46&t=...

  • Dari sudut pandang pemula Linux, menarik untuk memahami mengapa program bisa mendapat fitur seperti backspace, Ctrl+W, dan Ctrl+U "gratis" bahkan ketika hanya membaca teks dengan sesuatu seperti fgets()
    Dokumentasi fgets() mengatakan ia membaca sampai muncul newline atau EOF, jadi saya penasaran apakah itu berarti secara bawaan program diblokir sampai pengguna memasukkan newline, dan sebelum itu terminal mengizinkan buffer baris diedit dengan backspace atau Ctrl+W/Ctrl+U
    Namun program tidak harus selalu membaca satu baris penuh; ia bisa memberi count = 2 dan membaca per karakter. Kalau begitu, saat backspace terjadi, karakter yang sudah dibaca tidak mungkin “dikembalikan”, jadi saya penasaran apakah ada semacam sihir di buffer internal fgets() atau apakah dalam kasus seperti itu fitur pengeditan baris memang rusak
    https://en.cppreference.com/w/c/io/fgets

    • zsh, bash, ksh, fish, dan sebagian besar program UI terminal membiarkan terminal dalam mode cooked dan mengelola perilaku terminal sendiri. Dalam mode cooked, terminal tidak melakukan buffering per newline dan membaca semua karakter
      Yang terlihat seperti buffering berdasarkan newline sebenarnya dikelola oleh shell, sehingga pengembang bisa menambahkan fitur manipulasi buffer teks seperti pelengkapan tab atau menambahkan sudo di depan baris
    • Secara bawaan terminal berjalan dalam mode kanonik (canonical mode). Tidak ada I/O yang terjadi sampai pengguna memasukkan satu baris lengkap
      Sebelum Enter ditekan, karakter di layar hanya ada di memori terminal, dan system call read milik aplikasi tetap terblokir pada file descriptor terminal. Terminal tidak menulis data sampai barisnya lengkap
      Pada saat ini, pengeditan baris yang sedang diketik juga biasanya disediakan oleh terminal itu sendiri. Karakter yang tampil di layar juga merupakan fitur terminal yang disebut echo, begitu juga backspace, delete, Ctrl+C untuk SIGINT, dan Ctrl+D untuk EOF
      Editor baris dan editor teks mematikan fitur-fitur ini lalu memakai mode raw. Semua input yang diketik langsung dikirim ke aplikasi dan ditangani sendiri. Prompt kata sandi yang hanya mematikan echo untuk menyembunyikan karakter juga merupakan contoh umum
      Akhiran baris Unix tradisional \n sebenarnya juga fitur terminal. Dari sudut pandang terminal, \n hanya memindahkan kursor satu baris ke bawah, jadi untuk kembali ke awal baris juga dibutuhkan \r. Akhiran baris yang sebenarnya adalah \r\n, dan terminal diam-diam mengubah \n menjadi \r\n. Ini juga bisa dinonaktifkan
    • Fitur ini disediakan oleh emulator terminal dalam mode “cooked”: https://en.wikipedia.org/wiki/Terminal_mode
      Dalam mode raw, ini tidak bekerja seperti itu
    • Salah satu tugas pertama saya yang dibayar sebagai programmer adalah mem-porting program help di VMS ke SunOS. Rintangan pertama adalah bagaimana membuatnya merespons setiap penekanan tombol alih-alih menunggu Enter/Return
      Atasan saya sengaja hampir tidak membantu, dan pada 1986 saat web belum ada dan buku O’Reilly pun hampir belum ada, saya dibiarkan mencari tahu hampir sendirian. Sampai sekarang saya tetap sangat bersyukur atas keputusan itu

  • Shell dash juga mendukung mode pengeditan jika dikompilasi dengan libedit. Distribusi turunan Debian mungkin tidak melakukannya karena alasan ruang, tetapi menurut saya jika ingin orang yang mulai dengan bash tidak perlu banyak belajar ulang nanti, sebaiknya fitur itu didukung
    Standar POSIX juga menetapkan set -o vi sebagai ekstensi opsional. Jika sebuah shell yang mengklaim kompatibel POSIX mengimplementasikan mode pengeditan ini, maka ia wajib mendukung set -o vi
    “[set -o] vi: mengizinkan pengeditan baris perintah shell menggunakan editor vi bawaan. Saat mode vi diaktifkan, mode pengeditan baris perintah lain yang disediakan sebagai ekstensi implementasi harus dinonaktifkan.”
    https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

    • dash di Debian dimaksudkan sebagai sh POSIX ringan untuk menjalankan skrip shell. Ia tidak ditujukan sebagai shell login atau penggunaan interaktif, jadi dalam konteks itu menjaga dependensi tetap ringan adalah hal yang masuk akal

  • Saya selalu berpikir terminal adalah satu faktor tunggal yang membuat Linux selamanya terjebak di pangsa pasar di bawah 5%
    Bukan hanya input teks yang jadi masalah; seluruh pengalamannya rumit. 95% populasi cuma ingin menerbangkan drone, tetapi yang disodorkan malah kokpit Concorde tanpa label
    https://qph.cf2.quoracdn.net/main-qimg-2566f4c91b894e4169d77..., https://media.thedroningcompany.com/images/tincy/WQZpC56vqMp...

    • Itu benar jika yang ada hanya distro bergaya LFS, Gentoo, dan Arch, tetapi selama ada Ubuntu, Mint, OpenSUSE, Fedora, Manjaro, dan banyak distro ramah pengguna lainnya, argumen itu jadi kurang meyakinkan
      Saya justru bersyukur ada kokpit Concorde di balik Ubuntu, dan saya bisa mengaksesnya dari laptop kerja Ubuntu saya. Rasanya saya tidak akan suka jika tidak punya tingkat kendali seperti itu
      Sebaliknya, laptop ibu saya juga memakai Ubuntu dan laptop pacar saya memakai Manjaro; keduanya tidak pernah sekalipun menyentuh kokpit Concorde dan baik-baik saja hanya dengan “menerbangkan drone”. Tentu saja, saya sendiri memakai Arch
    • Linux kernel tanpa terminal dan sebagian user space-nya sebenarnya sudah dipakai mayoritas orang dalam bentuk Android dan Chromebook
      Terminal adalah alat untuk developer dan administrator sistem. Hanya terlihat seperti itu karena sebagian besar pengguna desktop GNU/Linux memang developer dan administrator sistem, dan mereka hanya beberapa persen dari populasi
    • Di Gnome Terminal milik Ubuntu atau Windows Terminal di Windows, Home untuk ke awal baris dan End untuk ke akhir baris berfungsi, jadi hal-hal yang mudah diketik rasanya sama mudahnya di mana-mana
      Justru terminal macOS yang mengharuskan tahu banyak shortcut aneh; semuanya dibuat seolah sengaja se-tidak-intuitif mungkin
    • Yang membuat pangsa pasar Linux kecil adalah kurangnya preinstall. Bahkan Windows pun pada dasarnya hampir tidak dipakai siapa pun sampai Microsoft pada era 3.x nyaris memaksakan bundling OEM dan preinstall
    • Sebaliknya, pengalaman terminal GNU/Linux yang lebih baik daripada Unix mungkin menjadi salah satu alasan ia mengalahkan Unix. Masuk ke box BSD terasa seperti melakukan perjalanan waktu ke tahun 1980-an

  • Mungkin ini pendapat yang tidak populer, tetapi di iTerm2 saya menggantinya ke preset Natural text editing agar sesuai dengan shortcut pengeditan macOS tradisional
    Karena di dalam aplikasi terminal biasanya itu dipetakan ulang menjadi control sequence, kelebihannya adalah fungsinya hampir selalu tersedia di mana-mana tanpa perlu mengubah banyak hal atau mengkhawatirkan dukungan readline
    Memang tidak sempurna, jadi kadang sequence yang perlu saya ketik manual ikut ter-remap, tetapi karena sesuai dengan muscle memory saya, saya jadi jauh lebih sering menggunakan pengeditan perintah
    https://pliszko.com/blog/post/2021-10-31-natural-text-editin...

    • Ini salah satu hal pertama yang saya atur setelah memasang iTerm. Bisa memakai Cmd+panah, Option+panah, Cmd+Delete, dan Option+Delete secara alami itu sangat penting
      Saya tidak ingin pengeditan teks di terminal bekerja secara istimewa atau berbeda sendiri

  • Tiga key binding readline dasar yang akan membuat hidup orang lebih baik jika mereka tahu adalah Ctrl+W, Ctrl+O, dan Ctrl+R
    Ctrl+W menghapus kata terakhir, seperti yang disebut Julia dalam artikelnya
    Ctrl+O menjalankan baris yang dipanggil dari riwayat, lalu memanggil lagi baris riwayat berikutnya. Jika pindah ke perintah pertama dalam riwayat lalu menekan Ctrl+O lima kali, Anda bisa menjalankan lima perintah secara berurutan
    Ctrl+R mencari ke belakang dalam riwayat sambil Anda mengetik string pencarian. Menekan Ctrl+R lagi berpindah ke hasil sebelumnya, Ctrl+S bergerak maju secara kronologis. Jalankan dengan Enter atau Ctrl+O

    • Saya selalu penasaran kenapa Ctrl+S yang dipilih. Dari pengalaman saya, itu berbenturan dengan pause XOFF yang hampir selalu menjadi default di mana-mana
      Jika ingin memakai kombinasi tombol itu untuk fitur pencarian maju, Anda harus tahu dulu kenapa tidak berfungsi, dan juga mau menonaktifkan XOFF
    • Selama ini saya selalu melakukan fitur terakhir itu dengan Ctrl+Shift+R, seperti Shift+Tab di GUI. Senang juga jadi tahu soal Ctrl+S, tetapi karena muscle memory, sepertinya saya tetap tidak akan bisa memakainya

  • Di Windows Terminal, Ctrl+C selalu berfungsi dengan benar. Jika sedang memilih teks, itu akan menyalin, dan jika tidak sedang memilih, itu akan mematikan proses yang sedang berjalan
    Aplikasi terminal Linux tidak memakai Ctrl+C untuk menyalin dan meminta Ctrl+Shift+C. Untuk menempel juga, kalau menekan Ctrl+V justru masuk karakter aneh, sementara di aplikasi lain semuanya Ctrl+V, jadi terus kena jebakan karena memori otot
    Penasaran apakah ada aplikasi terminal Linux yang berperilaku seperti Windows Terminal dan tidak memukul punggung tangan karena “penggunaan teletype yang tidak pantas”

    • Terminal selalu diatur agar menyalin saat memilih. Tidak menekan Ctrl+C. Sejak awal, kalau bukan untuk menyalin, kenapa memilih teks?
    • Fakta bahwa salin dan interupsi di terminal dipisah menjadi Command-C dan Ctrl-C adalah salah satu alasan terbesar saya tetap bertahan di Mac
    • Menyalin di dalam dan luar terminal dilakukan dengan tombol tengah mouse. Pilih teks lalu klik tombol tengah di posisi tempat ingin menempel
      Cara ini memakai buffer Xorg terpisah, jadi setelah menyalin sesuatu dengan Ctrl+C lalu memilih teks lain, Ctrl+V akan menempelkan yang pertama dan klik tengah akan menempelkan yang kedua
      Di Windows atau ponsel, kadang menyebalkan ketika hanya memilih sesuatu lalu lupa menekan Ctrl+C atau semacamnya
      Sepertinya tidak ada terminal Linux yang bekerja seperti Windows Terminal. Soalnya program yang berjalan di dalam terminal mungkin ingin menangani Ctrl+C sendiri. Editor teks adalah salah satu contohnya, dan terminal juga tidak tahu program apa yang sedang berjalan saat ini. Karena kontrol pekerjaan adalah urusan shell
    • Kebanyakan terminal Linux yang bagus bisa diatur lewat konfigurasi. Misalnya di kitty, cukup pakai map ctrl+c copy_or_interrupt
      https://sw.kovidgoyal.net/kitty/actions/#action-copy_or_inte...
    • Sepertinya ini juga bisa dilakukan di WezTerm yang bisa dikonfigurasi dengan Lua. Karena saya sudah menjalankan fungsi Lua tertentu dengan key binding lain, begitu kembali ke depan laptop saya berencana mencoba membuatnya berfungsi