भविष्य का टर्मिनल

• मौजूदा टर्मिनल संरचना की जटिलता और सीमाओं की ओर संकेत करते हुए, input, output और process control को नए सिरे से एकीकृत करने वाली next-generation terminal की अवधारणा प्रस्तुत की गई है
• Jupyter Notebook को मॉडल मानकर, image rendering, command re-execution, editable output, built-in editor जैसी interactive interface क्षमताओं की संभावना तलाश की गई है
• Warp और iTerm2 के उदाहरणों के माध्यम से shell और terminal के बीच deep integration (shell integration), long-running process management, session detachment और recovery features को विस्तार से समझाया गया है
• dataflow tracking और persistence के आधार पर command के undo/redo, automatic re-execution, collaborative terminal जैसी विस्तारित क्षमताओं की कल्पना की गई है
• चरणबद्ध तरीके से transactional CLI → persistent sessions → structured RPC → Jupyter-जैसा frontend तक विकसित करने की incremental build strategy प्रस्तुत की गई है

---

टर्मिनल की बुनियादी संरचना

• टर्मिनल चार घटकों से मिलकर बना होता है: terminal emulator, virtual terminal (PTY), shell, process group
  • terminal emulator वह प्रोग्राम है जो स्क्रीन पर grid structure render करता है
  • PTY kernel के भीतर की state है, जो input को process group तक पहुँचाता है और signal conversion संभालता है
  • shell input को पढ़ता, parse करता और process बनाता है, यानी यह एक event loop की भूमिका निभाता है
  • processes input और output के माध्यम से ऊपर के घटकों के साथ interact करते हैं
• input सिर्फ साधारण text नहीं होता, इसमें signal भी शामिल होते हैं, और output ANSI escape sequences से बना होता है जो formatting को व्यक्त करते हैं

बेहतर टर्मिनल की कल्पना

• मौजूदा टर्मिनल में कार्यात्मक सीमाएँ बहुत हैं, इसलिए उसमें extensibility और interactivity की कमी है
• Jupyter Notebook ऐसे features देता है जो पारंपरिक VT100 emulator में संभव नहीं हैं
  • high-resolution image rendering
  • पुराने output को जोड़ने के बजाय बदलने वाला "शुरू से फिर चलाएँ" बटन
  • source code और output को उसी जगह दोबारा लिखने योग्य "view" (उदाहरण: Markdown को source या rendered HTML के रूप में दिखाना)
  • syntax highlighting, tabs, panels, mouse support आदि वाला built-in editor
• लेकिन shell को kernel की तरह इस्तेमाल करने वाला Jupyter Notebook मॉडल कई समस्याओं का सामना करता है
  • shell एक बार में command लेता है, इसलिए tab completion, syntax highlighting, autosuggestion काम नहीं करते
  • long-running process handling की समस्या: Jupyter मूल रूप से cell के पूरा होने तक चलता है; cancel तो किया जा सकता है, लेकिन pause, resume, interaction, running process देखना संभव नहीं
  • "cell re-run" बटन कंप्यूटर की state में समस्या पैदा कर सकता है, खासकर जब उसमें rm -rf जैसे command हों
  • undo/redo काम नहीं करता

यह कैसे काम करेगा?

• shell integration

  • Warp terminal, terminal और shell के बीच native integration बनाता है
    • terminal हर command की शुरुआत और अंत, output, और user input को समझता है
    • यह standard features (custom DCS) का उपयोग करके लागू किया गया है
  • iTerm2 भी इसी तरह OSC 133 escape code का उपयोग कर सकता है
    • एक ही shortcut key से commands के बीच navigation
    • command पूरा होने पर notification
    • जब output स्क्रीन से बाहर चला जाए, तो मौजूदा command को "overlay" के रूप में दिखाना

• long-running process management

  • interaction:
    • long-running process के साथ interact करने के लिए bidirectional communication की आवश्यकता होती है
      • TUI उदाहरण: top, gdb, vim
      • Jupyter, बदलने और update होने योग्य interactive output डिज़ाइन में मजबूत है
    • अपेक्षित terminal feature: हमेशा एक "free input cell" उपलब्ध हो
      • interactive process विंडो के ऊपर चले और नीचे input cell दिया जाए
  • suspending:
    • process को "suspend" करना "job control" कहलाता है
    • आधुनिक terminal से उम्मीद है कि वह suspended और background processes को लगातार visual indicator के साथ दिखाएगा
      • जैसे IntelliJ नीचे task bar में "Indexing..." दिखाता है
  • disconnecting: session detachment और recovery के लिए तीन तरीके हैं
    • Tmux / Zellij / Screen: terminal emulator और program के बीच एक अतिरिक्त terminal emulator डाला जाता है। server PTY का मालिक होता है, output render करता है, और client वास्तविक terminal emulator पर output दिखाता है। client detach, reconnect, और एक साथ कई clients को connect कर सकता है। iTerm, tmux client को bypass करके server से सीधे बात करने वाले अपने client की तरह काम करता है
    • Mosh: SSH का विकल्प। network interruption के बाद terminal session से दोबारा जुड़ने की सुविधा देता है। server पर state machine चलती है और viewport के incremental differences को client पर replay किया जाता है। multiplexing और scrollback terminal emulator द्वारा संभाले जाने की अपेक्षा होती है। क्योंकि client वास्तव में network side पर चलता है, इसलिए local line editing तुरंत होता है
    • alden/shpool/dtach/abduco/diss: client/server के रूप में सिर्फ session detach/resume को संभालते हैं; networking या scrollback शामिल नहीं करते, और अपना terminal emulator भी नहीं रखते। tmux और mosh की तुलना में अलगाव का स्तर अधिक है

• re-execution और rollback

  • समाधान है data flow tracking
  • pluto.jl आज Julia compiler से जुड़कर इसे लागू करता है
    • पहले के cell पर निर्भर cells को real time में update करता है
    • dependency न बदलने पर cell update नहीं करता
    • यह spreadsheet जैसा Jupyter है, जहाँ ज़रूरत होने पर ही code फिर से चलता है
  • orthogonal persistence के माध्यम से इसका सामान्यीकरण
    • process को sandbox किया जाता है और सभी I/O को track किया जाता है, जिससे sandbox के भीतर दूसरे process के साथ communication न होने तक बहुत "अजीब" चीज़ें रोकी जा सकती हैं
    • process को input का pure function माना जा सकता है, जहाँ input है "पूरा file system, सभी environment variables, और सभी process properties"

व्युत्पन्न सुविधाएँ

• Jupyter frontend की आवश्यकता:
  • Runbooks (असल में केवल Jupyter और PTY primitives से बनाया जा सकता है)
  • किसी अजीब custom language या ANSI color codes के बिना साधारण CSS का उपयोग करने वाला terminal customization
  • output/timestamp के आधार पर command search: अभी पूरे मौजूदा session के output में खोज सकते हैं या सभी command input history में खोज सकते हैं, लेकिन smart filters नहीं हैं और output sessions के बीच persist नहीं होता
• shell integration की आवश्यकता:
  • हर command का timestamp और execution time
  • network boundary पार करने पर भी local line editing
  • tab दबाए बिना shell commands के लिए IntelliSense, terminal में integrated rendering
• sandbox tracking की आवश्यकता:
  • sandbox tracking की सभी क्षमताएँ: collaborative terminal, command द्वारा बदली गई files की query, runtime पर editable asciinema, build system tracking
  • smart search को इस तरह बढ़ाना कि command execution के समय disk state में भी खोज सके
  • undo/redo को git जैसी branching model तक विस्तारित करना (emacs undo-tree पहले से इसे support करता है), और process tree के कई "views" देना
  • undo-tree model और sandboxing के जरिए LLM को project access देकर कई instances को एक साथ parallel में चलाना संभव होगा, बिना एक-दूसरे की state overwrite किए; उनके काम को देखा, edit किया और बाद में इस्तेमाल के लिए runbook के रूप में save किया जा सकेगा
  • production environment में machine state को प्रभावित किए बिना केवल मौजूदा state inspect करने वाला terminal

चरणबद्ध निर्माण रणनीति

• चरण 1: transactional semantics

  • terminal को फिर से डिज़ाइन करते समय terminal emulator से शुरुआत करना गलत तरीका है
    • users emulator से जुड़ाव रखते हैं और उसकी configuration, appearance, key bindings सेट करते हैं
    • emulator बदलने की लागत बहुत अधिक होती है
  • CLI layer से शुरुआत करना सही तरीका है
    • CLI program install और run करना आसान होता है, और switching cost बहुत कम होती है
    • इसे पूरे workflow को बदले बिना one-off तरीके से इस्तेमाल किया जा सकता है
  • terminal के लिए transactional semantics लागू करने वाला CLI लिखना
    • transaction [start|rollback|commit] जैसा interface
    • start के बाद चलायी गई हर चीज़ को undo किया जा सके
    • सिर्फ इससे भी पूरा business बनाया जा सकता है

• चरण 2: persistent sessions

  • transactional semantics मिलने के बाद tmux और mosh में persistence को अलग करना
  • PTY persistence पाने के लिए client/server model लाना ज़रूरी है
    • kernel मानता है कि PTY के दोनों सिरों का हमेशा connected रहना अपेक्षित है
    • alden जैसे command या मिलती-जुलती library का उपयोग करके इसे सरलता से लागू किया जा सकता है, बिना terminal emulator या PTY session के अंदर चल रहे programs को प्रभावित किए
  • scrollback के लिए server input/output को अनिश्चित काल तक store करे और client के reconnect होने पर replay करे
    • terminal emulator native scrollback देगा, जिसे किसी और output की तरह handle किया जाएगा
    • किसी भी मनचाहे starting point से replay और resume संभव होगा
    • ANSI escape codes parsing की ज़रूरत होगी, लेकिन पर्याप्त मेहनत से यह संभव है
  • mosh जैसी network resume क्षमता के लिए Eternal TCP का उपयोग (इसे QUIC के ऊपर बनाकर efficiency बढ़ाई जा सकती है)
    • PTY persistence और network connection persistence को अलग किया जाता है
    • Eternal TCP एक शुद्ध optimization है: इसे ssh host eternal-pty attach को loop में चलाने वाली bash script के ऊपर भी बनाया जा सकता है
  • इस बिंदु पर tmux की तरह एक terminal session से कई clients connect हो सकते हैं, जबकि window management अभी भी terminal emulator संभालेगा
    • अगर integrated window management चाहिए, तो terminal emulator iTerm की तरह tmux -CC protocol का उपयोग कर सकता है
  • इस चरण के सभी हिस्से transactional semantics से स्वतंत्र रूप से parallel में किए जा सकते हैं, लेकिन केवल इनसे business बनाना पर्याप्त नहीं है

• चरण 3: structured RPC

  • यह client/server model पर निर्भर करता है
  • जब terminal emulator और client के बीच server मौजूद हो, तो metadata के साथ I/O tagging जैसी सुविधाएँ लागू की जा सकती हैं
    • हर data में timestamp जोड़ा जा सकता है
    • input और output में अंतर किया जा सकता है
    • xterm.js भी कुछ ऐसा ही करता है
  • shell integration के साथ मिलाकर data layer पर shell prompt और program output को अलग किया जा सकता है
  • terminal session का structured log प्राप्त किया जा सकता है
    • asciinema की तरह logs को recording के रूप में replay करना
    • सभी commands को फिर से चलाए बिना shell prompt बदलना
    • Jupyter Notebook या Atuin Desktop में import करना
    • commands को save करके बाद में script की तरह फिर चलाना
    • terminal खुद data बन जाता है

• चरण 4: Jupyter-जैसा frontend

  • यह पहला चरण है जहाँ terminal emulator को छुआ जाता है, और जानबूझकर इसे आख़िर में रखा गया है
    • क्योंकि switching cost सबसे अधिक है
  • अब तक बनाई गई सभी सुविधाओं का उपयोग करके अच्छा UI देना
  • transaction CLI की अब ज़रूरत नहीं रहेगी, जब तक nested transactions न चाहिए हों
    • पूरा terminal session डिफ़ॉल्ट रूप से transaction के रूप में शुरू होगा
  • क्योंकि सभी हिस्से जुड़ चुके होंगे, ऊपर बताई गई सारी व्युत्पन्न सुविधाएँ उपलब्ध होंगी

निष्कर्ष

• यह संरचना साहसी और महत्वाकांक्षी है, और पूरे निर्माण में लगभग 10 साल तक लग सकते हैं
• धैर्य रखते हुए इसे चरणबद्ध तरीके से आगे बढ़ाना होगा
• उम्मीद है कि यह लेख किसी को प्रेरित करेगा कि वह खुद इसे बनाना शुरू करे