Terminalde metin girişi neden karmaşıktır

 (jvns.ca)
1 puan yazan GN⁺ 2024-07-09 | 1 yorum | WhatsApp'ta paylaş
  • Komut satırında metin düzenlemek temel bir özellik gibi görünse de, programların girişi işleme biçimi farklı olduğundan aynı tuş tamamen farklı şekilde çalışabilir
  • Terminaldeki giriş deneyimi genel olarak dört akışa ayrılır: giriş sistemi olmaması, GNU readline, libedit gibi alternatif kütüphaneler ve özel giriş sistemleri
  • cat, nc, dash gibi basit araçlarda ok tuşları ^[[D gibi görünebilir, ancak terminalin sunduğu Ctrl+W, Ctrl+U, Ctrl+C, Ctrl+Z yine de kullanılabilir
  • bash, psql, irb, python3 gibi readline tabanlı araçlar geçmiş, ok tuşları, Ctrl+R araması, Ctrl+A/Ctrl+E ile gezinme sağlar; benzer bir deneyim rlwrap ile de eklenebilir
  • Mevcut giriş sistemini ayırt edebilirseniz, ok tuşlarının veya Ctrl+R'nin neden farklı göründüğünü hızlıca anlayabilir ve gerekirse belgeye bakma ya da rlwrap gibi geçici çözümler seçme işi kolaylaşır

Programa göre değişen giriş deneyimi

  • Terminalde metin girme ve düzenleme biçimi programdan programa büyük ölçüde değişir
  • Başlıca türler kabaca şöyle ayrılır
    • cat, nc, git commit --interactive gibi araçlar ok tuşlarını desteklemez; bu yüzden ^[[D^[[D^[[C^[[C^ gibi dizeler görebilirsiniz
    • irb, Linux'taki python3 gibi araçlar readline kütüphanesiyle geçmiş ve ok tuşları gibi temel düzenleme işlevleri sunar
    • Mac'teki /usr/bin/python3 gibi bazı durumlarda ok tuşları çalışır ama Ctrl+left ya da Ctrl+R ile ters yönde arama desteklenmez
    • fish, ipython3, micro, vim gibi araçlar kendi giriş sistemlerini kullanır

Mod 1: Giriş sistemi olmayan temel durum

  • Bir program fgets() gibi çağrılarla yalnızca metin alıyor ve ayrı bir düzenleme özelliği sunmuyorsa, ok tuşları düzenleme komutu yerine kaçış dizisi olarak yazdırılabilir
  • Örneğin dash içinde sol ok tuşuna bastığınızda terminale şöyle ^[[D yazılabilir
$ ls l-^[[D^[[D^[[D
  • Buna rağmen terminalin varsayılan olarak sunduğu kontrol işlevleri kalır
    • Metin girişi
    • Backspace
    • Ctrl+W: önceki kelimeyi sil
    • Ctrl+U: tüm satırı sil
    • Ctrl+C: süreci kes
    • Ctrl+Z: süreci duraklat
  • Böyle bir ortamda da Ctrl+W kullanarak backspace'e defalarca basmadan kelime bazında silebilirsiniz
  • Terminalin desteklediği kontrol kodlarını stty -a ile görebilirsiniz

Mod 2: readline kullanan araçlar

  • readline, metin girişini daha rahat hale getiren bir GNU kütüphanesidir ve birçok etkileşimli araçta kullanılır
  • Sık kullanılan readline kısayolları şunlardır
    • Ctrl+E veya End: satır sonuna git
    • Ctrl+A veya Home: satır başına git
    • Ctrl+left/right arrow: birer kelime ileri/geri git
    • Yukarı ok: önceki komuta git
    • Ctrl+R: geçmişte arama
  • Temel moddaki Ctrl+W, Ctrl+U da kullanılabilir; ancak readline içinde Ctrl+U tüm satırı değil, imleçten satır başına kadar olan kısmı siler
  • bash içindeki Ctrl+R geçmiş araması, readline'in sunduğu bir özelliktir
  • psql, irb, python3 da readline kullanan programlara örnektir
  • Readline düzenleme komutlarının tam listesi readline kılavuzunda görülebilir

Readline olmayan araçlara rlwrap eklemek

  • nc gibi readline desteklemeyen programları rlwrap nc ile çalıştırırsanız, readline destekli bir program gibi kullanabilirsiniz
  • rlwrap, readline olmayan araçların kullanılabilirliğini ciddi ölçüde artırabilir
  • Özel otomatik tamamlama da ayarlanabilir, ancak bunun fiilen denenmiş bir anlatımı değil

Araçlar neden readline kullanmaz?

  • Bazı araçların readline kullanmamasının birkaç nedeni vardır
    • cat, nc gibi çok basit programlar görece büyük bir bağımlılık eklemek istemeyebilir
    • Readline, LGPL değil GPL lisanslıdır; bu da programın lisansıyla uyumsuz olabilir
    • Programın yalnızca bir bölümü etkileşimliyse ve giriş y ya da n gibi tek karaktere yakınsa, readline desteğinin önceliği düşük olabilir
  • git, git add -p gibi etkileşimli özelliklere sahip olsa da, anlamlı uzunlukta girdi gerektiğinde genelde bir metin düzenleyici açar
  • idris2, bağımlılıkları en aza indirmek için readline kullanmaz; daha iyi etkileşimli özellikler gerekiyorsa rlwrap kullanmayı önerir

Şu anda readline kullanılıp kullanılmadığını anlama

  • En basit kontrol yöntemi Ctrl+R tuşuna basmaktır
  • Şu istemi görüyorsanız readline kullanılıyor olma ihtimali yüksektir
(reverse-i-search)`':
  • Başka kütüphaneler de aynı terimi kullanabilir, bu yüzden kesin bir test değildir; ancak geçmiş aramasında reverse-i-search ifadesini kullanan başka bir sistem biliniyor değil

Readline kısayolları ve Emacs

  • Ctrl+A ile satır başına, Ctrl+E ile satır sonuna gitme kısayolları Emacs kökenli sayılabilir
  • Emacs'te de Ctrl+A ve Ctrl+E, readline ile aynı işi yapar
  • Buna karşılık Ctrl+W, Ctrl+U Emacs ile terminalde aynı davranmaz
  • Readline projesinin geçmişi hakkında daha fazlası Readline proje tarihinde bulunabilir

Mod 3: libedit gibi alternatif giriş kütüphaneleri

  • Mac'teki /usr/bin/python3, yalnızca bazı readline özelliklerini destekleyen ara bir durumda sayılabilir
  • Örneğin Ctrl+left arrow tuşuna bastığınızda kelime geçişi yerine ;5D yazılabilir
$ python3
>>> importt subprocess;5D
  • Mac OS varsayılan Python kurulumunda Python readline modülü gerçekte libedit tabanlıdır
  • Bunun nedeninin readline'in GPL lisansı olduğu tahmin ediliyor
  • Bu Python'un libedit kullanıp kullanmadığını şu komutla kontrol edebilirsiniz
$ python3 -c "import readline; print(readline.__doc__)"
Importing this module enables command line editing using libedit readline.
  • Linux'ta veya Homebrew ile kurulan Python genelde readline kullanır
  • Python 3.13, readline bağımlılığını kaldırıp kendi kütüphanesini kullanmayı planlıyor; bu yüzden gelecekte “Python readline kullanır” ifadesi her zaman doğru olmayabilir

Mod 4: Özel giriş sistemleri

  • Bazı programlar kendi metin düzenleme sistemlerini kullanır ve bazen readline'dan daha fazla özellik sunar
  • Özel giriş sistemi kullanan örnekler şunlardır
    • nano, micro, vim, emacs gibi çoğu terminal metin düzenleyicisi
    • fish gibi kabuklar
    • zsh'nin satır düzenleyicisi zle
    • ipython gibi REPL'ler
    • atuin gibi araçlar
  • Bu sistemlerde şu özellikleri görebilirsiniz
    • Araca daha uygun otomatik tamamlama
    • Sözdizimi vurgulaması içeren daha iyi geçmiş yönetimi
    • Daha fazla klavye kısayolu

Readline'dan ilham alan özel giriş sistemleri

  • Atuin, kabuk geçmişi arama aracıdır; giriş uygulaması kendine ait olsa da yaklaşımı readline'dan esinlenmiştir
  • Atuin, kullanıcıların readline tuş atamalarına alışkın olmasından yararlanır ve readline'i doğrudan kullanmasa bile bu tuş atamalarını çalıştırır
  • IPython'ın kullandığı prompt_toolkit da birçok seçenek sunar; buna vi tarzı tuş atamaları da dahildir
  • prompt_toolkit'in varsayılanı readline tarzı tuş atamalarını desteklemektir
  • Bu, birçok programın aşağı için j, yukarı için k gibi temel vim tuş atamalarını desteklemesine benzer
  • Örneğin Fastmail, kısayollarının çoğu vim ile çok ilgili olmasa da j, k destekler
  • Readline'dan ilham alan bu özel giriş sistemleri readline ile ince farklarla uyumsuz olabilir; ancak yalnızca birkaç temel kısayol kullanan kullanıcılar için bu büyük bir sorun olmayabilir
  • Bu özel sistemler genelde yalnızca readline kullanmaya göre daha iyi otomatik tamamlama sağlayabilir

vi modunu destekleyen kabuklar

  • bash, zsh, fish metin girişi için vi modu destekler
  • Mastodon'da yapılan bilimsel olmayan ankette, katılımcıların %12'si vi modunu kullandığını söyledi
  • Readline'in kendisinde de vi modu vardır; bash içindeki vi modu desteği bunun üzerinden çalışır
  • Readline kullanan başka birçok program da vi moduna sahip olabilir

Giriş durumunu teşhis etme akışı

  • Hangi giriş sisteminin kullanıldığını bilmek, komut satırı davranışını daha öngörülebilir hale getirir
  • Giriş isteminde şu sırayla değerlendirme yapabilirsiniz
    • Ok tuşları çalışmıyorsa büyük olasılıkla giriş sistemi yoktur; buna rağmen Ctrl+W, Ctrl+U kullanılabilir ve gerekirse rlwrap eklenebilir
    • Ctrl+R ile reverse-i-search görünüyorsa bunun readline olma ihtimali yüksektir; tanıdık readline kısayolları ve temel geçmiş özellikleri kullanılabilir
    • Ctrl+R farklı davranıyorsa bunun özel bir giriş kütüphanesi olma ihtimali yüksektir; genelde readline'a benzer çalışabilir ve gerekirse belgeler kontrol edilebilir
  • Burada ele alınmayan başka giriş karmaşıklıkları da vardır
    • ssh, tmux ile ilgili sorunlar
    • TERM ortam değişkeni
    • GNOME Terminal, iTerm, xterm gibi terminaller arasında kopyala-yapıştır desteği farkları
    • Unicode
    • ve diğer çeşitli giriş sorunları

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-09
Hacker News yorumları

  • Julia’nın yazıları her zaman iyi oluyor. Eksik kalan bir nokta: kabuk betiği içinde stty kullanırsanız, giriş işleme biçimi dahil terminalin birçok davranışını değiştirebilirsiniz.
    Eskiden sh ve stty ile yaptığım bir deney: https://gist.github.com/alganet/63f1dbc97b8fd35f7bb14ec30f79...
    VT100 uyumlu terminallerde (mintty, xterm, Terminal.app, vscode vb.) çoğu tuş kombinasyonunu ve fare jestlerini (basma/sürükleme/bırakma) bile kabuk içinde yakalayıp yorumlayabilirsiniz.
    Çalışan demo bash -c "$(curl -L https://git.io/fjToH)"; tuşlara basmayı veya fareyi hareket ettirmeyi deneyebilirsiniz. Çıkış Ctrl+W. zsh ve ksh de destekleniyor, ancak read -rn1 olmayan dash gibi kabuklar desteklenmiyor.
    Ayrıca vi | cat -v gibi etkileşimli bir programı cat -v’ye pipe ederseniz, o programın kullandığı VT100 escape dizilerini görebilirsiniz; vi’nin bunu nasıl yaptığını izleyerek çok şey öğrendim.

    • Komutu çalıştırdıktan sonra terminal bozulur, çıktı görünmez ya da garip karakterler görünürse, ilgili komut tty temizliğini düzgün yapmamış olabilir. Terminali öldürmeyin; stty sane yazarsanız eski hâline döndürebilirsiniz.
    • Kernighan’ın UNIX Programming Environment kitabının başlarını okurken, benzer bir ruhla terminal giriş/çıkış davranışını keşfetmek için şöyle tuhaf bir yöntem düşünmüştüm.
      3 terminal açıp 1) man ascii, 2) nc -lvp 9001 | xxd -c1, 3) stty raw -echo; nc -nv 127.0.0.1 9001 çalıştırın; ardından 3. terminalde manpage’deki “Hex” sütununun tamamını sırayla yeniden üretmeye çalışın.
      Bazı değerlerin birden fazla şekilde üretilebildiğini, başka tuşlardan bazılarının da çok baytlı payload gönderdiğini gözlemleyebilirsiniz.
    • Terminal metin düzenleyicisi uygulamayı anlatan bu yazı da stty ve raw mode’u anlamama yardımcı olmuştu: https://viewsourcecode.org/snaptoken/kilo/, https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode...
      Büyü gibi görünen stty parametreleri ve sembolleri, çok eskiden tanımlanmış kontrol dizilerinden geliyor. ECMA-48 gibi 1970’lerden kalma muğlak standartlarda, bugün neredeyse hiç kullanılmayan pek çok anlaşılması zor terim de var.
      Örneğin Select Graphic Rendition(SGR) kabaca 1970’ler versiyonu HTML etiketi gibi bir şey; ön plan rengini ayarlamak için ESC[38;2;R;G;BmTextESC[0m benzeri bir yapı kullanılır. ESC[ CSI, m SGR, 38 ön plan rengi, 2 RGB renk uzayı, 0 ise stil sıfırlamadır.
      Komuttan önce parametrelerin gelmesi biraz ters hissettiriyor. Tarayıcılarda olduğu gibi terminallerde de neyin nasıl uygulandığı her zaman farklıydı ve hâlâ öyle. Renk desteği oldukça iyi, ama diğer özellikler için aynı şey geçerli değil. Örneğin SGR<7> “negative image” modu olarak geçiyor, fakat standart bunu ayrıntılı açıklamadığı için bazı terminaller ters görüntüleme yapıyor, bazıları başka şekilde ele alıyor; bu da bugün bile sorun çıkarıyor.
    • İnternetten kodu doğrudan bash’e çekmeden önce her zaman kontrol etmek gerekir. Bu demo benim standart dışı ayarlarımı tuhaf şekilde bozmuş gibiydi; ayrıntılı kayıt tutmayı düşünmedim.
    • Sonoma’da “The invoked shell does not support interactive features” çıkıyor.

  • 20 yıldan da fazla önce readline üzerinde bir durum makinesi kurup, yalnızca bir satırın sarılmasından ibaret olmayan, yukarı-aşağı hareket edilebilen gerçek bir çok satırlı düzenleyici gibi kullanılmasını sağlamıştım.
    Video: https://github.com/colmmacc/jot/raw/master/jot-demo.mp4
    Bu özelliği içeren Unix terminal IM istemcisinin CVS deposu: https://c-hey.redbrick.dcu.ie/src/c-hey_cvs_latest/
    Satırlar arasında yukarı-aşağı hareket ederken imleci izleyip yeniden çiziyor; terminal boyutu değişirse SIGWINCH’i izleyip tekrar çiziyor. Rust ile yeniden yazıp küçük bir kütüphane olarak yayımlamak istiyorum ama zaman bulamadım. Kimsenin benzer bir şey yapmamış olması beni hep şaşırtmıştır.

    • Oldukça havalı; fikri almak isterim. Belirli bir durumda zsh’te birkaç satırla uygulanabilir gibi.
      autoload -Uz zed ardından zed kullanarak geçici bir dosyayı düzenleyip git commit -F’ye verirseniz, ZLE’nin tüm özelliklerine sahip satır içi bir düzenleyici başlatabilirsiniz. C-x C-w ile kaydedip commit edebilir, C-c ile iptal edebilirsiniz.
      Bu temel uygulamanın avantajı, zed’in yeni bir ZLE widget’ı olması sayesinde keymap üzerinde tam kontrol sağlamasıdır. emacs modu veya vi modu doğrudan çalışır, ayrıca daha da özelleştirilebilir.
      Kendi ZLE widget’ınızı yazarsanız, satır düzenleyicinin içinden doğrudan çağırabilirsiniz; böylece yukarıdaki gibi komutu sarmaya da gerek kalmaz.
      https://github.com/zsh-users/zsh/blob/master/Functions/Misc/...
    • Videoyu izleyene kadar bu düzenleme deneyiminin ne kadar daha iyi olduğunu bilmiyordum; git commit’in etkileşimli modu gibi bağlam değiştirmek zorunda kalmama avantajına katılıyorum. “Satır içi daktilo” gibi etkisi de hoş.
    • rio’nun metin penceresi hold modundayken de benzer görünüyor. Ancak tasarımı çok daha basit ve fare desteği daha iyi: https://p9f.org/magic/man2html/1/rio
    • Programın mevcut sürümünün kararlı olup olmadığını merak ediyorum.

  • Yazıda atlananlar arasında geniş karakterler, klavye modu farkları yüzünden aynı tuş girişinin farklı ANSI escape dizileriyle temsil edilmesi sorunu, yerel echo gibi TTY durum farklılıkları ve TTY durumunu değiştiren sistem çağrılarının işletim sistemine göre ince farklar göstermesi var.
    Terminal emülasyonu desteği de her yerde farklı. Günümüzde genelde xterm taklit ediliyor ama bunun içinde bile %100 uyumluluğu hedefleyen pek yok.
    Terminalin sunduğu özellikleri denetleme yönteminde de uzlaşma eksik. Kimisi ANSI escape dizisi gönderip yanıt bekliyor, kimisi $TERMe bakıyor, bazı terminaller kendini xterm olarak gösterirken VT özellik dizilerini yok sayıp başka ortam değişkenleri ayarlıyor. Açıkçası kullanıcı ajanı dizgelerinden bile daha karmaşık.
    Bütün bunlar POSIX sistemleri varsayımıyla geçerli; Windows’u da işin içine katınca iki kat ilginçleşiyor.

  • bash’te $EDITORı sevdiğiniz düzenleyiciye ayarlarsanız Ctrl-X Ctrl-E ile mevcut satırı $EDITORa gönderebilirsiniz. Komutu düzenleyip kaydedip çıktığınızda çalıştırılır.

    • ksh’de vi modu kullanan eski bir Unix kurduysanız sadece vye basmanız da yeterli.
    • fc yerleşik komutu da aynı işi yapar. Ctrl tuş dizilerine gerek olmadan sadece fc yazabilirsiniz.
      Önceki komutu varsayılan $EDITOR yerine belirli bir düzenleyiciyle de açabilirsiniz. Örneğin EDITOR=vi iken bir önceki komutu ed ile düzenlemek için fc -e ed kullanılır.
      vi modunda komut geçmişinden hızlıca shell betiği oluşturmanın bir yolu da var. İstediğiniz komut geçmişte 15. sıradaysa fc 15 ardından w1.sh, %d, wq gibi işlemlerle halledilebilir.
    • fish’te Alt-e.
    • Bu tür kısayolları seviyorum ama tam ihtiyaç olduğunda hatırlayamıyorum.
    • Neovim’de EDITOR=nvim ile copilot.vim’i birlikte kullanıp yapay zeka destekli shell otomatik tamamlama gibi kullanıyorum. Gayet iyi.
      Bunu burada görmüştüm: https://twitter.com/arjie/status/1575201117595926530?s=46&t=...

  • Linux’a yeni başlayan biri olarak, bir program yalnızca fgets() gibi bir şeyle metin okusa bile backspace, Ctrl+W, Ctrl+U gibi özelliklerin nasıl bedavaya geldiğini merak ediyorum.
    fgets() belgelerinde newline ya da EOF gelene kadar okuduğu yazıyor; bu, varsayılan olarak kullanıcı newline girene kadar bloklandığı ve ondan önce terminalin satır tamponunu backspace veya Ctrl+W/Ctrl+U ile düzenlemeye izin verdiği anlamına mı geliyor, merak ediyorum.
    Ama programın her zaman tüm satırı okuyacağının garantisi yok; count 2 verilerek karakter karakter de okunabilir. O zaman backspace gerçekleştiğinde zaten okunmuş karakteri “geri almak” mümkün olmayacak gibi; fgets() iç tamponunda bir sihir mi var, yoksa böyle durumlarda satır düzenleme özelliği mi bozuluyor, merak ediyorum.
    https://en.cppreference.com/w/c/io/fgets

    • zsh, bash, ksh, fish ve çoğu terminal UI programı terminali cooked modda bırakarak terminal davranışını doğrudan yönetir. Cooked modda terminal newline tamponlaması yapmaz, tüm karakterleri okur.
      Newline’a göre tamponlanıyormuş gibi görünmesinin nedeni bunu aslında shell’in yönetmesidir; bu yüzden geliştiriciler sekme tamamlama veya satırın başına sudo ekleme gibi metin tamponu işleme özellikleri koyabilir.
    • Varsayılan olarak terminal kanonik modda (canonical mode) çalışır. Kullanıcı tam bir satır girmeden giriş/çıkış gerçekleşmez.
      Enter’a basılmadan önce ekrandaki karakterler yalnızca terminal belleğindedir; uygulamanın read sistem çağrısı terminal dosya tanımlayıcısında bloklanmış durumdadır. Satır tamamlanana kadar terminal veri yazmaz.
      Bu sırada girilmekte olan satırın düzenlenmesini de genelde terminalin kendisi sağlar. Karakterlerin ekranda görünmesi de echo denen bir terminal özelliğidir; backspace, delete, SIGINT için Ctrl+C ve EOF için Ctrl+D de aynı şekilde.
      Satır düzenleyicileri ve metin düzenleyicileri bu özellikleri kapatıp terminali ham moda (raw mode) alır. Girilen her şey anında uygulamaya iletilir ve doğrudan orada işlenir. Parola istemlerinin karakterleri gizlemek için yalnızca echo’yu kapatması da yaygın bir örnektir.
      Geleneksel Unix satır sonu \n de aslında bir terminal özelliğidir. Terminal açısından \n imleci yalnızca bir satır aşağı taşır; satır başına dönmek için \r de gerekir. Gerçek satır sonu \r\n’dir ve terminal görünmez biçimde \ni \r\ne çevirir. Bu da devre dışı bırakılabilir.
    • Bu özelliği “cooked” moddaki terminal emülatörü sağlar: https://en.wikipedia.org/wiki/Terminal_mode
      raw modda böyle çalışmaz.
    • Programcı olarak para aldığım ilk işlerden biri VMS’in help programını SunOS’a port etmekti. İlk engel Enter/Return beklemeden her tuş girişine tepki verme yolunu bulmaktı.
      Patronum bilerek neredeyse hiç yardım etmedi; web’in olmadığı, O’Reilly kitaplarının da çok az olduğu 1986’da bunu neredeyse tek başıma çözmemi sağladı. O karar için hâlâ sonsuza dek minnettarım.

  • dash shell’i de libedit ile derlenirse düzenleme modunu destekler. Debian türevleri muhtemelen alan kaygısıyla böyle yapmıyor ama bash ile başlayanların daha sonra daha az şey öğrenmek zorunda kalması isteniyorsa desteklenmesi gerektiğini düşünüyorum.
    POSIX standardı da set -o viyi isteğe bağlı bir genişletme olarak belirtir. POSIX uyumlu olduğunu iddia eden bir shell bu düzenleme modunu uyguluyorsa mutlaka set -o viyi desteklemelidir.
    “[set -o] vi: yerleşik vi düzenleyicisini kullanarak shell komut satırı düzenlemeye izin verir. vi modu açıldığında, uygulama genişletmesi olarak sağlanan diğer komut satırı düzenleme modları devre dışı bırakılmalıdır.”
    https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

    • Debian’daki dash, shell betikleri çalıştırmak için tasarlanmış hafif bir POSIX sh olarak amaçlanmıştır. Login shell veya etkileşimli kullanım hedeflenmediği için, bu bağlamda bağımlılıkları hafif tutmak mantıklı.

  • Terminalin Linux’u sonsuza kadar %5’in altında pazar payına mahkûm eden tek faktör olduğunu düşünmeye devam ettim
    Sorun yalnızca metin girişi değil, tüm deneyim karmaşık. Nüfusun %95’i sadece drone uçurmak istiyor; onların önüne etiketsiz bir Concorde kokpiti koymak gibi
    https://qph.cf2.quoracdn.net/main-qimg-2566f4c91b894e4169d77..., https://media.thedroningcompany.com/images/tincy/WQZpC56vqMp...

    • Yalnızca LFS, Gentoo, Arch tarzı dağıtımlar olsaydı bu doğru olurdu; ama Ubuntu, Mint, OpenSUSE, Fedora, Manjaro ve sayısız kullanıcı dostu dağıtım varken pek ikna edici değil
      Ubuntu’nun arkasında bir Concorde kokpiti olması ve iş için kullandığım Ubuntu dizüstümde oraya erişebilmem bence aksine minnet duyulacak bir şey. O düzeyde denetimim olmasa hoşuma gitmezdi
      Öte yandan annemin dizüstü de Ubuntu, kız arkadaşımın dizüstü ise Manjaro; ikisi de Concorde kokpitine hiç adım atmadan sadece “drone uçurarak” gayet iyi kullanıyor. Tabii ben Arch kullanıyorum
    • Terminalsiz Linux çekirdeği ve bazı kullanıcı alanı, Android ve Chromebook biçiminde çoğunluk tarafından zaten kullanılıyor
      Terminal geliştiricilerin ve sistem yöneticilerinin aracıdır. Masaüstü GNU/Linux kullanıcılarının çoğu geliştirici ve sistem yöneticisi olduğu için öyle görünür; bunlar da nüfusun ancak birkaç yüzdesidir
    • Ubuntu’daki Gnome Terminal’de ya da Windows’taki Windows Terminal’de Home ile satır başına, End ile satır sonuna gidebilirsiniz; girişi kolay olan şeylerin hepsi benzer şekilde kolay görünüyor
      Tuhaf kısayolların çoğunu bilmeniz gereken yer daha çok macOS terminali; orada her şey mümkün olduğunca daha az sezgisel yapılmış
    • Linux’un düşük pazar payını yaratan şey önceden kurulu gelmemesi. Windows’u da Microsoft 3.x döneminde OEM paketleri ve ön kurulumları neredeyse dayatana kadar aslında kimse kullanmıyordu
    • Tersinden bakınca, GNU/Linux’un terminal deneyiminin Unix’ten daha iyi olması Unix’i geride bırakmasının nedenlerinden biri olabilir. Bir BSD makinesine giriş yaptığınızda 1980’lere zaman yolculuğu yapmış gibi oluyorsunuz

  • Muhtemelen popüler olmayan bir görüş olacak ama iTerm2’de Natural text editing ön ayarına geçip geleneksel macOS düzenleme kısayollarıyla uyumlu hale getirdim
    Terminal uygulamasının içinde genelde denetim dizilerine yeniden eşlendiği için, birçok yerde ayar değiştirmeniz ya da readline desteğini dert etmeniz gerekmeden neredeyse her yerde bu işlevleri elde etme avantajı var
    Kusursuz değil; ara sıra elle girmem gereken dizilerin yeniden eşlendiği oldu, ama kas hafızama uyduğu için komut düzenlemeyi çok daha fazla kullanır oldum
    https://pliszko.com/blog/post/2021-10-31-natural-text-editin...

    • iTerm’i kurunca ilk ayarladığım şeylerden biri. Cmd+ok tuşları, Option+ok tuşları, Cmd+Delete, Option+Delete kombinasyonlarını doğal biçimde kullanabilmek çok önemli
      Terminalde metin düzenlemenin özel bir şekilde davranmasını istemiyorum

  • İnsanlar bilse hayatlarını iyileştirecek üç temel readline tuş ataması Ctrl+W, Ctrl+O, Ctrl+R
    Ctrl+W, Julia’nın yazıda belirttiği gibi son kelimeyi siler
    Ctrl+O, geçmişten çağrılan satırı çalıştırır ve ardından geçmişteki sonraki satırı tekrar çağırır. Geçmişte ilk komuta gidip Ctrl+O’ya beş kez basarsanız beş komutu sırayla çalıştırabilirsiniz
    Ctrl+R, arama dizgesini yazarken geçmişte geriye doğru arama yapar. Ctrl+R’ye tekrar basarsanız önceki sonuca, Ctrl+S ise zaman açısından ileriye gider. Enter veya Ctrl+O ile çalıştırırsınız

    • Ctrl+S’nin neden seçildiğini hep merak etmişimdir. Deneyimlerime göre neredeyse her yerde varsayılan olan XOFF duraklatma ile çakışıyor
      İleriye doğru arama için o tuş kombinasyonunu kullanmak istiyorsanız, neden çalışmadığını bilmeniz ve XOFF’u kapatmaya istekli olmanız gerekir
    • Son işlevi GUI’de Shift+Tab yapar gibi her zaman Ctrl+Shift+R ile kullanıyordum. Ctrl+S’yi öğrenmek güzel ama kas hafızası yüzünden muhtemelen kullanamayacağım

  • Windows Terminal’da Ctrl+C her zaman doğru çalışır. Metin seçiliyken kopyalar, seçili değilken çalışan süreci sonlandırır
    Linux’taki terminal uygulamaları Ctrl+C ile kopyalama yapmaz, Ctrl+Shift+C ister. Yapıştırmak için Ctrl+V’ye basınca da garip karakterler girilir; diğer tüm uygulamalarda Ctrl+V olduğu için kas hafızası yüzünden sürekli yakalanırsınız
    Windows Terminal gibi davranıp “uygunsuz teletayp kullanımı” diye elinizin üstüne vurmayan bir Linux terminal uygulaması var mı merak ediyorum

    • Terminali, seçim yapıldığında her zaman kopyalayacak şekilde ayarlıyorum. Ctrl+C’ye basmıyorum. Zaten kopyalamayacaksam metni neden seçeyim ki
    • Terminalde kopyalama ve sonlandırmanın Command-C ile Ctrl-C olarak ayrılmış olması, Mac’te kalmamı sağlayan en büyük nedenlerden biri
    • Terminal içinde ve dışında kopyalamayı orta fare düğmesi ile yaparım. Metni seçip yapıştırmak istediğiniz yerde orta düğmeye tıklamanız yeterli
      Bu yöntem ayrı bir Xorg tamponu kullandığından, Ctrl+C ile bir şeyi kopyaladıktan sonra başka bir metin seçseniz bile Ctrl+V ilkini yapıştırır, orta tıklama ise ikincisini yapıştırır
      Windows’ta veya akıllı telefonda, bir şeyi sadece seçip Ctrl+C gibi bir şeye basmayı unuttuğum için sinir olduğum zamanlar oluyor
      Linux terminalleri arasında Windows Terminal gibi yapan pek yoktur sanırım. Çünkü terminal içinde çalışan program Ctrl+C’yi doğrudan işlemek isteyebilir. Metin düzenleyiciler buna örnektir; terminal o anda hangi programın çalıştığını da bilmez. İş denetimi kabuğun görevidir
    • İyi Linux terminallerinin çoğunda bu ayarla yapılabilir. Örneğin kitty’de map ctrl+c copy_or_interrupt kullanmak yeterli
      https://sw.kovidgoyal.net/kitty/actions/#action-copy_or_inte...
    • Lua ile yapılandırılabilen WezTerm’de de yapılabilir gibi. Başka bir tuş bağlamasıyla belirli bir Lua fonksiyonu çalıştırıyorum; dizüstü bilgisayarın başına geçince bunu çalışır hâle getirmeyi deneyeceğim