टर्मिनल में टेक्स्ट इनपुट जटिल क्यों होता है

 (jvns.ca)
1 पॉइंट द्वारा GN⁺ 2024-07-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कमांड लाइन में टेक्स्ट को संपादित करना एक बुनियादी सुविधा जैसा लगता है, लेकिन हर प्रोग्राम इनपुट को अलग तरह से संभालता है, इसलिए एक ही key बिल्कुल अलग तरह से काम कर सकती है
  • टर्मिनल इनपुट अनुभव मोटे तौर पर चार तरह में बंटता है: बिना इनपुट सिस्टम, GNU readline, libedit जैसी वैकल्पिक लाइब्रेरी, और अपना खुद का इनपुट सिस्टम
  • cat, nc, dash जैसे सरल tools में arrow keys दबाने पर ^[[D जैसा टेक्स्ट दिख सकता है, लेकिन टर्मिनल द्वारा दिए गए Ctrl+W, Ctrl+U, Ctrl+C, Ctrl+Z अब भी काम करते हैं
  • bash, psql, irb, python3 जैसे readline-आधारित tools history, arrow keys, Ctrl+R search, और Ctrl+A/Ctrl+E navigation देते हैं, और rlwrap से ऐसा ही अनुभव जोड़ा जा सकता है
  • मौजूदा इनपुट सिस्टम की पहचान कर लेने पर यह जल्दी समझ आता है कि arrow keys या Ctrl+R अलग क्यों दिख रहे हैं, और ज़रूरत होने पर docs देखना या rlwrap जैसे workaround चुनना आसान हो जाता है

प्रोग्राम के अनुसार बदलता इनपुट अनुभव

  • टर्मिनल में टेक्स्ट दर्ज करने और संपादित करने का तरीका हर प्रोग्राम में काफ़ी अलग होता है
  • प्रमुख प्रकार मोटे तौर पर इस तरह बंटते हैं
    • cat, nc, git commit --interactive आदि arrow keys को support नहीं करते, इसलिए ^[[D^[[D^[[C^[[C^ जैसी string दिख सकती है
    • irb, Linux का python3 आदि readline लाइब्रेरी की मदद से history और arrow keys जैसी बुनियादी editing सुविधाएँ देते हैं
    • Mac के /usr/bin/python3 की तरह कुछ मामलों में arrow keys तो काम करती हैं, लेकिन Ctrl+left या Ctrl+R reverse search support नहीं होता
    • fish, ipython3, micro, vim आदि अपना खुद का इनपुट सिस्टम इस्तेमाल करते हैं

मोड 1: बिना इनपुट सिस्टम की बुनियादी स्थिति

  • अगर कोई प्रोग्राम fgets() जैसे call से सिर्फ टेक्स्ट लेता है और अलग editing सुविधा नहीं देता, तो arrow keys editing command की जगह escape sequence के रूप में छप सकती हैं
  • उदाहरण के लिए dash में left arrow दबाने पर टर्मिनल में यह दिख सकता है
$ ls l-^[[D^[[D^[[D
  • फिर भी टर्मिनल की डिफ़ॉल्ट control सुविधाएँ बनी रहती हैं
    • टेक्स्ट इनपुट
    • backspace
    • Ctrl+W: पिछला शब्द हटाना
    • Ctrl+U: पूरी पंक्ति हटाना
    • Ctrl+C: process interrupt
    • Ctrl+Z: process suspend
  • ऐसे माहौल में भी Ctrl+W का इस्तेमाल करके कई बार backspace दबाने की बजाय शब्द के हिसाब से मिटाया जा सकता है
  • टर्मिनल कौन से control codes support करता है, यह stty -a से देखा जा सकता है

मोड 2: readline इस्तेमाल करने वाले tools

  • readline टेक्स्ट इनपुट को अधिक सुविधाजनक बनाने वाली GNU लाइब्रेरी है, और कई interactive tools में इस्तेमाल होती है
  • अक्सर इस्तेमाल होने वाले readline shortcuts ये हैं
    • Ctrl+E या End: पंक्ति के अंत में जाना
    • Ctrl+A या Home: पंक्ति की शुरुआत में जाना
    • Ctrl+left/right arrow: एक-एक शब्द आगे-पीछे जाना
    • ऊपर वाला arrow: पिछले command पर जाना
    • Ctrl+R: history search
  • बुनियादी मोड के Ctrl+W, Ctrl+U यहाँ भी इस्तेमाल किए जा सकते हैं, लेकिन readline में Ctrl+U पूरी पंक्ति नहीं बल्कि cursor से पंक्ति की शुरुआत तक हटाता है
  • bash का Ctrl+R history search, readline द्वारा दिया गया feature है
  • psql, irb, python3 आदि भी readline इस्तेमाल करने वाले प्रोग्रामों के उदाहरण हैं
  • readline editing commands की पूरी सूची readline manual में देखी जा सकती है

readline न होने वाले tools में rlwrap लगाना

  • nc जैसे प्रोग्राम, जो readline support नहीं करते, उन्हें rlwrap nc की तरह चलाने पर readline-enabled प्रोग्राम जैसा इस्तेमाल किया जा सकता है
  • rlwrap readline के बिना tools की usability काफ़ी बढ़ा सकता है
  • इसमें custom autocomplete भी सेट किया जा सकता है, हालांकि इसका वास्तविक उपयोग यहाँ नहीं किया गया है

कुछ tools readline क्यों नहीं इस्तेमाल करते

  • कुछ tools के readline न इस्तेमाल करने के कई कारण हो सकते हैं
    • cat, nc जैसे बहुत सरल प्रोग्राम अपेक्षाकृत बड़ी dependency जोड़ना नहीं चाहते होंगे
    • readline LGPL नहीं बल्कि GPL license के तहत है, इसलिए यह किसी प्रोग्राम के license से मेल नहीं खा सकता
    • अगर किसी प्रोग्राम का सिर्फ़ एक छोटा हिस्सा interactive हो और इनपुट y या n जैसे एकल character तक सीमित हो, तो readline support की प्राथमिकता कम हो सकती है
  • git में git add -p जैसी interactive सुविधाएँ हैं, लेकिन जब अर्थपूर्ण लंबा इनपुट चाहिए होता है, तब वह आमतौर पर text editor खोलता है
  • idris2 dependency कम रखने के लिए readline का उपयोग नहीं करता, और बेहतर interactive फीचर्स चाहिए हों तो rlwrap इस्तेमाल करने का सुझाव देता है

कैसे पहचानें कि अभी readline इस्तेमाल हो रहा है या नहीं

  • सबसे आसान तरीका है Ctrl+R दबाकर देखना
  • अगर यह prompt दिखे, तो readline इस्तेमाल होने की संभावना काफ़ी अधिक है
(reverse-i-search)`':
  • दूसरी लाइब्रेरियाँ भी यही शब्दावली इस्तेमाल कर सकती हैं, इसलिए यह पूरी तरह निर्णायक तरीका नहीं है, लेकिन history search के लिए reverse-i-search अभिव्यक्ति इस्तेमाल करने वाला कोई दूसरा सिस्टम आम तौर पर ज्ञात नहीं है

readline shortcuts और Emacs

  • Ctrl+A से पंक्ति की शुरुआत और Ctrl+E से अंत तक जाने वाले shortcuts को Emacs से आया हुआ माना जा सकता है
  • Emacs में भी Ctrl+A और Ctrl+E readline की तरह ही काम करते हैं
  • इसके विपरीत Ctrl+W, Ctrl+U Emacs और टर्मिनल में एक जैसा व्यवहार नहीं करते
  • readline project के इतिहास के बारे में Readline project history में और पढ़ा जा सकता है

मोड 3: libedit जैसी वैकल्पिक इनपुट लाइब्रेरियाँ

  • Mac का /usr/bin/python3 कुछ readline सुविधाएँ support करने वाली एक बीच की स्थिति जैसा है
  • उदाहरण के लिए Ctrl+left arrow दबाने पर शब्द के हिसाब से move होने की जगह ;5D छप सकता है
$ python3
>>> importt subprocess;5D
  • Mac OS की डिफ़ॉल्ट Python installation में Python का readline module वास्तव में libedit आधारित है
  • अनुमान है कि इसका कारण readline का GPL license होना है
  • नीचे दिया command चलाकर यह जाँचा जा सकता है कि वह Python libedit इस्तेमाल करता है या नहीं
$ python3 -c "import readline; print(readline.__doc__)"
Importing this module enables command line editing using libedit readline.
  • Linux या Homebrew से install किया गया Python आम तौर पर readline इस्तेमाल करता है
  • Python 3.13 readline dependency हटाकर अपनी लाइब्रेरी इस्तेमाल करने वाला है, इसलिए आगे चलकर “Python readline इस्तेमाल करता है” यह बात हमेशा सही नहीं रहेगी

मोड 4: अपना खुद का इनपुट सिस्टम

  • कुछ प्रोग्राम अपना खुद का टेक्स्ट editing सिस्टम इस्तेमाल करते हैं, और कभी-कभी readline से भी ज़्यादा सुविधाएँ देते हैं
  • ऐसे सिस्टम इस्तेमाल करने वाले उदाहरण ये हैं
    • nano, micro, vim, emacs जैसे अधिकांश terminal text editors
    • fish जैसा shell
    • zsh का line editor zle
    • ipython जैसा REPL
    • atuin जैसा tool
  • ऐसे सिस्टम में ये सुविधाएँ मिल सकती हैं
    • tool के अनुसार बेहतर autocomplete
    • syntax highlighting सहित बेहतर history management
    • अधिक keyboard shortcuts

readline से प्रेरित कस्टम इनपुट सिस्टम

  • Atuin shell history search tool है, और इसका इनपुट implementation खुद का है, लेकिन तरीका readline से प्रेरित है
  • Atuin इस बात का लाभ उठाता है कि उपयोगकर्ता readline key bindings के आदी होते हैं, इसलिए सीधे readline इस्तेमाल किए बिना भी वही key bindings काम करें, ऐसा बनाया गया है
  • IPython द्वारा इस्तेमाल किया जाने वाला prompt_toolkit भी कई विकल्प देता है, जिनमें vi-style key bindings शामिल हैं
  • prompt_toolkit का default readline-style key bindings support है
  • यह उसी तरह है जैसे कई प्रोग्राम नीचे जाने के लिए j और ऊपर जाने के लिए k जैसी बुनियादी vim key bindings support करते हैं
  • उदाहरण के लिए Fastmail के अधिकांश shortcuts का vim से खास संबंध नहीं है, लेकिन वह j, k support करता है
  • readline से प्रेरित कस्टम इनपुट सिस्टम readline के साथ सूक्ष्म स्तर पर compatible न भी हों, फिर भी जो उपयोगकर्ता सिर्फ़ कुछ बुनियादी shortcuts इस्तेमाल करते हैं, उनके लिए यह बड़ी समस्या नहीं हो सकती
  • ऐसे कस्टम सिस्टम में अक्सर सिर्फ readline इस्तेमाल करने की तुलना में autocomplete बेहतर हो सकती है

vi mode support करने वाले shells

  • bash, zsh, fish सभी टेक्स्ट इनपुट के लिए vi mode support करते हैं
  • Mastodon पर हुए गैर-वैज्ञानिक सर्वे में 12% लोगों ने कहा कि वे vi mode इस्तेमाल करते हैं
  • readline में खुद भी vi mode है, और bash का vi mode support उसी से काम करता है
  • readline इस्तेमाल करने वाले कई दूसरे प्रोग्रामों में भी vi mode हो सकता है

इनपुट स्थिति पहचानने का तरीका

  • अगर पता हो कि कौन सा इनपुट सिस्टम इस्तेमाल हो रहा है, तो command line के व्यवहार का अनुमान लगाना आसान हो जाता है
  • इनपुट prompt पर मोटे तौर पर इस क्रम में समझा जा सकता है
    • अगर arrow keys काम नहीं करतीं, तो संभव है कि कोई इनपुट सिस्टम ही न हो; फिर भी Ctrl+W, Ctrl+U इस्तेमाल किए जा सकते हैं, और ज़रूरत पड़ने पर rlwrap जोड़ा जा सकता है
    • अगर Ctrl+R पर reverse-i-search दिखता है, तो readline होने की संभावना अधिक है, और परिचित readline shortcuts तथा बुनियादी history फीचर्स उपलब्ध होंगे
    • अगर Ctrl+R कुछ और करता है, तो संभव है कि कोई कस्टम इनपुट लाइब्रेरी हो; वह आम तौर पर readline जैसा व्यवहार कर सकती है, और ज़रूरत हो तो docs देखे जा सकते हैं
  • इन बातों के अलावा भी इनपुट से जुड़ी कई जटिलताएँ बची रहती हैं
    • ssh, tmux से जुड़े मुद्दे
    • TERM environment variable
    • GNOME Terminal, iTerm, xterm आदि अलग-अलग terminals में copy-paste support का अंतर
    • Unicode
    • और इनपुट से जुड़े कई अन्य मुद्दे

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-07-09
Hacker News की राय

  • Julia के लेख हमेशा अच्छे होते हैं। एक छूटी हुई बात यह है कि shell script के अंदर stty का इस्तेमाल करके terminal के कई व्यवहार बदले जा सकते हैं, जिनमें input processing का तरीका भी शामिल है
    पहले sh और stty के साथ किया गया मेरा experiment: https://gist.github.com/alganet/63f1dbc97b8fd35f7bb14ec30f79...
    VT100-compatible terminals (mintty, xterm, Terminal.app, vscode आदि) में ज़्यादातर key combinations और mouse gestures (press/drag/release) तक shell के अंदर capture और interpret किए जा सकते हैं
    running demo bash -c "$(curl -L https://git.io/fjToH)" है; keys दबाकर या mouse हिलाकर देख सकते हैं। बाहर निकलने के लिए Ctrl+W। zsh और ksh भी supported हैं, लेकिन dash जैसे shells जिनमें read -rn1 नहीं है, वे supported नहीं हैं
    साथ ही, vi | cat -v की तरह किसी interactive program को cat -v में pipe करने पर उस program द्वारा इस्तेमाल किए गए VT100 escapes दिख सकते हैं, और vi कैसे काम करता है यह देखकर मैंने बहुत कुछ सीखा

    • command चलाने के बाद अगर terminal खराब हो जाए, output न दिखे या अजीब characters दिखें, तो हो सकता है उस command ने tty cleanup ठीक से न किया हो। terminal को मारने की ज़रूरत नहीं; stty sane type करने से वापस ठीक हो सकता है
    • Kernighan की UNIX Programming Environment की शुरुआती chapters पढ़ते समय, इसी तरह की भावना से terminal I/O behavior explore करने के लिए मैंने यह अजीब तरीका सोचा था
      3 terminals खोलें और 1) man ascii, 2) nc -lvp 9001 | xxd -c1, 3) stty raw -echo; nc -nv 127.0.0.1 9001 चलाएँ, फिर terminal 3 में manpage के “Hex” column को क्रम से पूरा reproduce करके देखें
      देखा जा सकता है कि कुछ values कई तरीकों से बनाई जा सकती हैं, और कुछ दूसरी keys multi-byte payloads भेजती हैं
    • terminal text editor implement करने वाला यह लेख भी stty और raw mode समझने में मददगार था: https://viewsourcecode.org/snaptoken/kilo/, https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode...
      जादू जैसे लगने वाले stty parameters और symbols बहुत पहले define किए गए control sequences से आए हैं। ECMA-48 जैसे 1970s के अस्पष्ट standards में ऐसे कठिन terms भी बहुत हैं जो अब लगभग इस्तेमाल नहीं होते
      उदाहरण के लिए Select Graphic Rendition(SGR) मोटे तौर पर 1970s के HTML tags जैसा है; foreground color set करने के लिए ESC[38;2;R;G;BmTextESC[0m जैसा रूप इस्तेमाल होता है। ESC[ CSI है, m SGR है, 38 foreground color है, 2 RGB color space है, और 0 style reset है
      command से पहले parameters आने वाली संरचना थोड़ी उल्टी लगती है। browsers की तरह terminals में भी implementation का दायरा और तरीका अलग-अलग था, और आज भी है। colors का support काफी अच्छा है, लेकिन बाकी features का नहीं। मसलन SGR<7> को “negative image” mode कहा गया है, पर standard इसे विस्तार से समझाता नहीं; इसलिए कुछ terminals reverse display करते हैं, और दूसरे terminals इसे अलग तरह से handle करते हैं, जिससे आज भी दिक्कतें आती हैं
    • internet से code सीधे bash में खींचने से पहले हमेशा verify करना चाहिए। लगता है इस demo ने मेरी non-standard settings को अजीब तरह से बिगाड़ दिया था, और मैंने detail में record करने की जरूरत नहीं समझी
    • Sonoma में “The invoked shell does not support interactive features” दिखता है

  • 20 साल से भी पहले मैंने readline के ऊपर एक state machine बनाई थी, ताकि इसे सिर्फ एक line wrap होने तक सीमित न रखकर ऊपर-नीचे move किए जा सकने वाले असली multi-line editor की तरह इस्तेमाल किया जा सके
    video: https://github.com/colmmacc/jot/raw/master/jot-demo.mp4
    इस feature वाले Unix terminal IM client का CVS repository: https://c-hey.redbrick.dcu.ie/src/c-hey_cvs_latest/
    lines के बीच ऊपर-नीचे move करते समय cursor को track करके redraw करता है, और terminal size बदलने पर SIGWINCH देखकर फिर से draw करता है। इसे Rust में दोबारा लिखकर एक छोटी library के तौर पर publish करना चाहता हूँ, लेकिन समय नहीं मिला। यह हमेशा हैरान करता रहा कि किसी और ने ऐसा कुछ नहीं किया

    • यह काफी शानदार है, और मैं यह idea अपनाना चाहूँगा। कुछ खास cases में इसे zsh में कुछ lines में implement किया जा सकता है
      autoload -Uz zed के बाद zed का इस्तेमाल करके temporary file edit करें और उसे git commit -F को pass करें, तो ZLE की सारी capabilities वाला inline editor शुरू किया जा सकता है। C-x C-w से save करके commit करें और C-c से cancel करें
      इस basic implementation का फायदा यह है कि zed नया ZLE widget है, इसलिए keymap पर पूरा control हो सकता है। emacs mode या vi mode तुरंत काम करता है, और और भी customize किया जा सकता है
      अगर आप खुद ZLE widget लिखें, तो उसे line editor के अंदर सीधे call किया जा सकता है, इसलिए ऊपर की तरह command wrap करने की जरूरत भी नहीं रहती
      https://github.com/zsh-users/zsh/blob/master/Functions/Misc/...
    • video देखने से पहले मुझे पता नहीं था कि ऐसा editing experience कितना बेहतर है, और git commit के interactive mode की तरह context switch न करने के फायदे से मैं सहमत हूँ। “inline typewriter” जैसा effect भी बढ़िया है
    • rio की text window hold mode में होने पर भी कुछ वैसी ही लगती है। हालांकि design बहुत सरल है और mouse support बेहतर है: https://p9f.org/magic/man2html/1/rio
    • जानना चाहूँगा कि program का current version stable है या नहीं

  • लेख में छूटी बातों में wide characters, keyboard mode के फर्क की वजह से वही key input अलग-अलग ANSI escape sequences के रूप में दिखने की समस्या, local echo जैसी TTY state की भिन्नताएँ, और TTY state बदलने वाली system calls का operating system के हिसाब से हल्का-हल्का अलग होना शामिल है
    terminal emulation support भी हर जगह अलग है। आजकल ज़्यादातर xterm की नकल करते हैं, लेकिन उसके अंदर भी कोई 100% compatibility को लक्ष्य नहीं बनाता
    terminal कौन-सी सुविधाएँ देता है, यह पता करने के तरीके पर भी सहमति कम है। कुछ पक्ष ANSI escape sequence भेजकर response का इंतज़ार करते हैं, कुछ $TERM देखते हैं, और कुछ terminals खुद को xterm के रूप में expose करते हुए VT feature sequences को ignore करते हैं और दूसरे environment variables set करते हैं। सच कहूँ तो यह user agent string से भी ज़्यादा गड़बड़ है
    यह सब POSIX system मानकर है; Windows को भी मिला दें तो मामला दोगुना दिलचस्प हो जाता है

  • bash में $EDITOR को अपने पसंदीदा editor पर set कर दें, तो Ctrl-X Ctrl-E से current line को $EDITOR में भेज सकते हैं। command edit करने के बाद save करके exit करें तो वह execute हो जाती है

    • ksh में vi mode इस्तेमाल करने वाले पुराने Unix expert हैं तो बस v दबा सकते हैं
    • fc built-in command भी यही काम करता है। Ctrl key sequence के बिना बस fc type कर दें
      पिछली command को default $EDITOR के बजाय किसी खास editor में भी खोल सकते हैं। उदाहरण के लिए EDITOR=vi हो और ठीक पिछली command को ed में edit करना हो, तो fc -e ed इस्तेमाल करें
      vi mode में command history से जल्दी shell script बनाने का तरीका भी है। अगर चाहिए command history की 15वीं entry है, तो fc 15 के बाद w1.sh, %d, wq जैसे steps से काम हो सकता है
    • fish में यह Alt-e है
    • ऐसे shortcuts पसंद हैं, लेकिन असल में ज़रूरत पड़ने पर याद नहीं रहते
    • Neovim में EDITOR=nvim और copilot.vim को साथ इस्तेमाल करके AI shell autocomplete जैसा इस्तेमाल कर रहा हूँ। काफ़ी अच्छा है
      यहाँ देखा था: https://twitter.com/arjie/status/1575201117595926530?s=46&t=...

  • Linux beginner के नज़रिए से, अगर कोई program fgets() जैसी चीज़ से सिर्फ text पढ़ता है, तब भी backspace, Ctrl+W, Ctrl+U जैसी सुविधाएँ मुफ्त में कैसे मिल जाती हैं, यह जिज्ञासा वाली बात है
    fgets() documentation में लिखा है कि यह newline या EOF आने तक पढ़ता है, तो क्या इसका मतलब है कि default रूप से यह user के newline enter करने तक blocked रहता है, और उससे पहले terminal line buffer को backspace या Ctrl+W/Ctrl+U से edit करने देता है?
    लेकिन इसकी कोई guarantee नहीं कि program हमेशा पूरी line पढ़ेगा; count को 2 देकर character-by-character भी पढ़ सकता है। तब backspace होने पर पहले से पढ़े गए characters को “वापस” नहीं किया जा सकता होगा, तो क्या fgets() के internal buffer में कोई जादू है, या ऐसे case में line editing feature टूट जाता है?
    https://en.cppreference.com/w/c/io/fgets

    • zsh, bash, ksh, fish और ज़्यादातर terminal UI programs terminal को cooked mode में रखते हैं, ताकि terminal behavior को खुद manage कर सकें। cooked mode में terminal newline buffering नहीं करता और हर character पढ़ता है
      newline के आधार पर buffering जैसी जो चीज़ दिखती है, वह असल में shell manage करता है, इसलिए developer tab completion या line की शुरुआत में sudo जोड़ने जैसी text buffer manipulation सुविधाएँ डाल सकता है
    • default रूप से terminal canonical mode में काम करता है। user पूरी line input न कर दे, तब तक input/output नहीं होता
      Enter दबाने से पहले screen पर दिख रहे characters सिर्फ terminal memory में होते हैं, और application की read system call terminal file descriptor पर blocked रहती है। line पूरी होने तक terminal data नहीं लिखता
      इस दौरान input हो रही line की editing भी आम तौर पर terminal खुद देता है। अक्षरों का screen पर दिखना भी echo नाम की terminal feature है, और backspace, delete, SIGINT के लिए Ctrl+C, EOF के लिए Ctrl+D भी ऐसे ही हैं
      line editors और text editors इन features को बंद करके raw mode में रखते हैं। जो कुछ input किया जाता है, वह तुरंत application को भेजा जाता है और application खुद उसे handle करता है। password prompt में characters छिपाने के लिए सिर्फ echo बंद करना भी आम उदाहरण है
      पारंपरिक Unix line ending \n भी असल में terminal feature है। terminal के नज़रिए से \n cursor को सिर्फ एक line नीचे ले जाता है, इसलिए line की शुरुआत में लौटने के लिए \r भी चाहिए। असली line ending \r\n है, और terminal अदृश्य रूप से \n को \r\n में बदल देता है। इसे भी disable किया जा सकता है
    • यह feature “cooked” mode वाले terminal emulator देता है: https://en.wikipedia.org/wiki/Terminal_mode
      raw mode में यह इस तरह काम नहीं करता
    • programmer के रूप में paid job में शुरू में मिले tasks में से एक VMS के help program को SunOS पर port करना था। पहली मुश्किल थी Enter/Return का इंतज़ार किए बिना हर keypress पर react करने का तरीका
      boss ने जानबूझकर लगभग कोई मदद नहीं की, और 1986 में, जब web नहीं था और O’Reilly की किताबें भी बहुत कम थीं, मुझे लगभग अकेले ही पता लगाने दिया। आज भी उस फैसले के लिए हमेशा आभारी हूँ

  • dash shell भी libedit के साथ compile किया जाए तो editing mode support करता है। Debian परिवार शायद space की वजह से ऐसा नहीं करता, लेकिन जो लोग bash से शुरू करते हैं उन्हें बाद में कम सीखना पड़े, इसके लिए support करना सही लगता है
    POSIX standard भी set -o vi को optional extension के रूप में specify करता है। POSIX compatibility का दावा करने वाला shell अगर यह editing mode implement करता है, तो उसे set -o vi support करना ही होगा
    “[set -o] vi: built-in vi editor का उपयोग करके shell command-line editing की अनुमति देता है। vi mode चालू करने पर implementation extension के रूप में दिए गए अन्य command-line editing modes disable करने चाहिए।”
    https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

    • Debian का dash shell scripts चलाने के लिए एक हल्का POSIX sh होने के इरादे से बनाया गया है। login shell या interactive use इसका लक्ष्य नहीं है, इसलिए उस context में dependencies को हल्का रखना उचित है

  • मैं लगातार सोचता रहा हूँ कि terminal ही वह अकेला कारण है जो Linux को हमेशा के लिए 5% से कम market share में बाँधे रखता है
    समस्या सिर्फ text input नहीं है, पूरा experience ही जटिल है। 95% आबादी बस drone उड़ाना चाहती है, लेकिन उनके सामने बिना labels वाला Concorde cockpit रख दिया जाता है
    https://qph.cf2.quoracdn.net/main-qimg-2566f4c91b894e4169d77..., https://media.thedroningcompany.com/images/tincy/WQZpC56vqMp...

    • अगर सिर्फ LFS, Gentoo, Arch-style distributions ही होते, तो यह बात सही होती, लेकिन जब Ubuntu, Mint, OpenSUSE, Fedora, Manjaro और ढेरों user-friendly distributions मौजूद हैं, तो यह दलील कमज़ोर लगती है
      Ubuntu के पीछे Concorde cockpit है, और मेरे work Ubuntu laptop से वहाँ पहुँचा जा सकता है—इसके लिए मैं बल्कि आभारी हूँ। उस स्तर का control न हो तो मुझे अच्छा नहीं लगेगा
      दूसरी ओर, मेरी माँ का laptop भी Ubuntu है और मेरी girlfriend का laptop Manjaro है; दोनों Concorde cockpit में कदम रखे बिना सिर्फ “drone उड़ाना” करती हैं और आराम से इस्तेमाल कर रही हैं। हाँ, मैं Arch इस्तेमाल करता हूँ
    • terminal के बिना Linux kernel और कुछ user space को Android और Chromebook के रूप में ज़्यादातर लोग पहले से ही इस्तेमाल कर रहे हैं
      terminal developers और system administrators का tool है। बस desktop GNU/Linux users में ज़्यादातर developers और system administrators हैं, इसलिए ऐसा दिखता है; ये आबादी के बस कुछ प्रतिशत हैं
    • Ubuntu के Gnome Terminal या Windows के Windows Terminal में Home से line की शुरुआत और End से line के अंत में जा सकते हैं, और जो चीज़ें input में आसान हैं वे सब लगभग उतनी ही आसान लगती हैं
      जहाँ उल्टे बहुत सारे अजीब shortcuts जानने पड़ते हैं वह macOS terminal है, जिसमें हर चीज़ को जितना हो सके उतना कम intuitive बनाया गया है
    • Linux के कम market share की वजह pre-installation की कमी है। Windows भी Microsoft द्वारा 3.x के दौर में OEM bundles और pre-installation को लगभग जबरन लागू करने से पहले असल में लगभग कोई नहीं इस्तेमाल करता था
    • उल्टा, GNU/Linux का terminal experience Unix से बेहतर था, यह Unix पर इसके हावी होने की एक वजह हो सकती है। BSD box में login करें तो 1980s में time travel करने जैसा लगता है

  • शायद यह unpopular opinion होगा, लेकिन iTerm2 में Natural text editing preset पर बदलकर मैंने इसे traditional macOS editing shortcuts से मिला लिया
    terminal app के अंदर आम तौर पर control sequences में remap कर दिया जाता है, इसलिए कई जगहों पर बदलाव करने या readline support की चिंता किए बिना लगभग हर जगह यह सुविधा मिल जाती है
    यह perfect नहीं है, इसलिए कभी-कभी manually input करनी पड़ने वाली sequences भी remap हो जाती थीं, लेकिन यह muscle memory से मेल खाता है, इसलिए मैं command editing कहीं ज़्यादा इस्तेमाल करने लगा
    https://pliszko.com/blog/post/2021-10-31-natural-text-editin...

    • iTerm install करने के बाद यह उन पहली चीज़ों में से है जिन्हें मैं set करता हूँ। Cmd+arrow, Option+arrow, Cmd+Delete, Option+Delete को natural तरीके से इस्तेमाल कर पाना बहुत ज़रूरी है
      मैं नहीं चाहता कि terminal में text editing किसी खास अलग तरह से behave करे

  • तीन basic readline key bindings जिन्हें लोग जान लें तो जिंदगी बेहतर हो जाएगी: Ctrl+W, Ctrl+O, Ctrl+R
    Ctrl+W, जैसा Julia ने लेख में बताया है, आख़िरी word delete करता है
    Ctrl+O history से लाई गई line को execute करता है, और फिर अगली history line को फिर से load करता है। history में पहले command पर जाने के बाद Ctrl+O पाँच बार दबाएँ तो पाँच commands क्रम से execute कर सकते हैं
    Ctrl+R search string type करते हुए history में उल्टा search करता है। Ctrl+R फिर दबाने पर पिछले result पर जाता है, और Ctrl+S समय के हिसाब से आगे बढ़ता है। Enter या Ctrl+O से execute होता है

    • मैं हमेशा सोचता था कि Ctrl+S क्यों चुना गया। मेरे अनुभव में यह लगभग हर जगह default XOFF pause से टकराता है
      forward search feature के लिए वह key combination इस्तेमाल करना हो, तो यह जानना होगा कि यह क्यों काम नहीं कर रहा और XOFF बंद करने की इच्छा भी होनी चाहिए
    • आख़िरी feature को मैं GUI में Shift+Tab की तरह हमेशा Ctrl+Shift+R से करता आया हूँ। Ctrl+S के बारे में जानकर अच्छा लगा, लेकिन muscle memory की वजह से शायद इस्तेमाल नहीं कर पाऊँगा

  • Windows Terminal में Ctrl+C हमेशा सही तरह से काम करता है। अगर टेक्स्ट selected है तो उसे copy करता है, और selected नहीं है तो चल रहे process को मार देता है
    Linux के terminal apps Ctrl+C से copy नहीं करते और Ctrl+Shift+C मांगते हैं। paste के लिए भी Ctrl+V दबाने पर अजीब characters आ जाते हैं, और बाकी सभी apps में Ctrl+V होता है, इसलिए muscle memory के कारण बार-बार फंसता रहता हूं
    सोचता हूं कि क्या कोई Linux terminal app है जो Windows Terminal की तरह behave करे और “अनुचित teletype उपयोग” कहकर हाथ पर चपत न लगाए

    • मैंने terminal को हमेशा select करते ही copy करने के लिए set कर रखा है। Ctrl+C नहीं दबाता। शुरू से ही अगर copy नहीं करना है तो text select ही क्यों करूंगा
    • terminal में copy और terminate का Command-C और Ctrl-C में अलग होना उन सबसे बड़े कारणों में से एक है जिनकी वजह से मैं Mac पर बना रहता हूं
    • terminal के अंदर-बाहर copy middle mouse button से करता हूं। text select करें और जहां paste करना है वहां middle button click कर दें
      यह तरीका अलग Xorg buffer का इस्तेमाल करता है, इसलिए Ctrl+C से कुछ copy करने के बाद अगर कोई दूसरा text select भी कर लें, तो Ctrl+V पहला वाला paste करेगा और middle click दूसरा वाला paste करेगा
      Windows या smartphone पर कभी-कभी सिर्फ कुछ select करके छोड़ देने और Ctrl+C जैसी चीज दबाना भूल जाने से झुंझलाहट होती है
      Linux terminals में Windows Terminal जैसा करने वाला शायद कोई नहीं होगा। वजह यह है कि terminal के अंदर चल रहा program Ctrl+C को खुद handle करना चाह सकता है। text editor ऐसा ही एक उदाहरण है, और terminal को यह भी नहीं पता होता कि अभी कौन-सा program चल रहा है। job control तो shell का काम है
    • अच्छे Linux terminals में से ज्यादातर में settings से यह संभव है। उदाहरण के लिए kitty में map ctrl+c copy_or_interrupt इस्तेमाल कर सकते हैं
      https://sw.kovidgoyal.net/kitty/actions/#action-copy_or_inte...
    • Lua से configure किया जा सकने वाला WezTerm में भी शायद यह किया जा सकता है। मैं किसी दूसरी key binding से एक खास Lua function चला रहा हूं, इसलिए laptop के सामने पहुंचने पर इसे काम करवाकर देखने का सोच रहा हूं