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

 (jyn.dev)
8 पॉइंट द्वारा GN⁺ 2025-11-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मौजूदा टर्मिनल संरचना की जटिलता और सीमाओं की ओर संकेत करते हुए, 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 साल तक लग सकते हैं
  • धैर्य रखते हुए इसे चरणबद्ध तरीके से आगे बढ़ाना होगा
  • उम्मीद है कि यह लेख किसी को प्रेरित करेगा कि वह खुद इसे बनाना शुरू करे

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

1 टिप्पणियां

 
GN⁺ 2025-11-13
Hacker News राय

  • पूरा लेख पढ़कर लगा कि शुरुआत में यह बस NIH-स्टाइल wish list जैसा दिखता है
    जबकि टर्मिनल को बदल सकने वाले कई विकल्प पहले से मौजूद हैं, लेख में उनका ज़िक्र नहीं था
    उदाहरण के लिए Emacs एक Lisp-आधारित VM है, जिसमें functions को redefine करना आसान है और commands annotated functions होते हैं। आउटपुट buffers में मैनेज होता है, और कई windows व frames को tile रूप में सजाया जा सकता है। CLI को वैसे का वैसा इस्तेमाल किया जा सकता है (vterm, eat आदि), या REPL flow में बदला जा सकता है (shell-mode, eshell आदि)। graphics भी supported हैं, हालांकि पूरा 2D context नहीं है
    एक और उदाहरण Acme है, जो Emacs जैसा है, लेकिन यह एक interactive text environment है जहाँ हर text command बन सकता है। Smalltalk की सोच भी मिलती-जुलती थी, लेकिन वह IDE के अधिक करीब है

    • Emacs में Org-mode और org-babel हैं, इसलिए यह Jupyter notebook की तरह काम कर सकता है। यहाँ तक कि Jupyter kernels से भी बात कर सकता है
      मैंने Emacs में GPTel का उपयोग करके एक पुरानी Latin textbook PDF को अपने-आप टुकड़ों में काटा, OCR से उसे org-mode format में बदला। नतीजा यह हुआ कि किसी शब्द को चुनते ही dictionary lookup हो जाता है, और वाक्य चुनने पर LLM grammar analysis कर देता है। इस तरह 1970s का text editor एक future-style learning platform बन गया
    • मैं Acme के बारे में और जानना चाहता हूँ। इसे खोजना मुश्किल लगा।
      Emacs, Jupyter, VSCode जैसे platforms शक्तिशाली हैं, लेकिन वे पूरी तरह बने हुए applications से ज़्यादा customization-आधारित platforms हैं।
      अगर सच में innovation चाहिए, तो जटिल setup की जगह उसे Docker container या executable के रूप में आसानी से reproducible तरीके से वितरित करना चाहिए
    • मुझे लगता है लेख का मुख्य बिंदु टर्मिनल के data model को खोलना है। उसके ऊपर अलग-अलग features बन सकना ही अहम है
    • Emacs की अनोखी बात उसकी UI independence है। Elisp में लिखे apps terminal और GUI दोनों में एक जैसे चलते हैं। 20 साल पहले भी मैं terminal में Elisp लिखता था, और GUI users को उसका कोई फर्क महसूस नहीं होता था। ऐसा platform कहीं और नहीं है

  • यह सवाल है कि टर्मिनल की अगली पीढ़ी का विचार ज़रूरी नहीं कि text-based ही हो
    भविष्य का terminal API के रूप में हो सकता है, या OAuth authentication के ज़रिए remote calls ले सकता है। input और output अब CLI text न भी हों।
    इसकी जगह object-based input/output अपनाया जा सकता है, ताकि commands और data structures को API के रूप में explore किया जा सके।
    terminal 70s की विरासत है, और आज इससे बेहतर विकल्प पूरी तरह संभव हैं

    • असल में terminal text-centric नहीं बल्कि bidirectional token stream पर आधारित है। इसी सादगी की वजह से Unix-style composition संभव होती है।
      अगर JSON output जोड़ा जाए, तो jq जैसे tools से pipeline बनाई जा सकती है।
      इसकी सादगी, यानी “worse is better” दर्शन, की वजह से यह दशकों तक evolve कर पाया है
    • मैं भी CLI की standard input/output limits से सहमत हूँ। data और presentation का एक ही होना composability को सीमित करता है।
      PowerShell की तरह self-describing objects पास किए जाएँ, तो कहीं अधिक शक्तिशाली composition संभव है
      इससे जुड़े उदाहरण मैंने अपनी blog post में लिखे हैं
    • PowerShell दिलचस्प है, लेकिन इसमें एक कमी है कि यह धीरे-धीरे programming language के और करीब पहुँच जाता है।
      command-based intuitive flow गायब हो जाता है, और API structure याद रखनी पड़ती है।
      अगर AI-based autocomplete और object structure exploration हो, तो यह कमजोरी कुछ हद तक दूर हो सकती है
    • मैं भी Nushell मज़े से इस्तेमाल करता हूँ। यह PowerShell से अधिक साफ-सुथरा है और Microsoft पर निर्भर नहीं है
      https://www.nushell.sh/
    • non-text-based terminal alternatives पहले से मौजूद हैं।
      लेकिन text-based evolved terminal की बात तभी रोचक लगती है जब उसके लिए कल्पना की जा सकने वाली ठोस proposal भी हो

  • terminal अब तक इसलिए बचा रहा है क्योंकि उसमें compatibility और automation की क्षमता है
    GUI की तुलना में scripting आसान है, और हर चीज़ reproducible तथा searchable होती है
    पहले Neovim का alt-screen switching मुझे असुविधाजनक लगता था, लेकिन ऐसे छोटे UX details भी महत्वपूर्ण हैं
    जब मैंने पहली बार computer को जाना था, और फिर जब terminal सीखा, तब मैं दो बार उससे प्रेम में पड़ा

  • संबंधित projects में

    • Arcan — TUI applications के लिए एक नया protocol प्रस्तावित करता है
    • Shelter — Git-जैसा branchable filesystem shell
    • Shelter को filesystem snapshots चाहिए, लेकिन विचार सच में शानदार है
    • मुझे लगता है कि Arcan का ज़िक्र किए बिना लिखा गया लेख अधूरा है। यह पहले से usable है
      • इसका नाम पहली बार सुना, सच में दिलचस्प है। लिंक के लिए धन्यवाद

  • 18 महीने पहले मैंने Windows Terminal में ऐसा ही एक प्रयोग किया था
    यह GitHub comment में दर्ज है
    लेकिन Polyglot Notebooks इस्तेमाल करने के बाद मैं उधर चला गया, क्योंकि वह कहीं अधिक natural लगा
    imperative backend को Jupyter kernel से बदलकर, उसे notebook-style interactive documents की तरह इस्तेमाल करना कहीं अधिक efficient है

    • मैं भी ऐसी ही किसी system की तलाश में था। यह LLM या personal work environment के लिए अधिक उपयुक्त लगता है
    • Windows Terminal में notebook का concept डालना सच में शानदार विचार है। ऐसी कोशिशें और होनी चाहिए

  • पहले मैंने TopShell नाम से एक project में functional programming-आधारित shell+terminal बनाया था
    https://github.com/topshell-language/topshell#readme
    इसमें संभावना है, लेकिन पूरी तरह का विकल्प बनने के लिए अभी बहुत काम बाकी है

  • मैं ऐसा terminal खोज रहा था जो images या videos दिखा सके
    अच्छा होगा अगर कोई terminal बस browser की तरह भी काम कर सके।
    जैसे browser google.com/maps कमांड देकर उसे सीधे interactive रूप में खोला जा सके

    • लेकिन ऐसी functionality terminal की नहीं बल्कि अलग program (fbi, omxplayer आदि) की भूमिका है

  • प्रस्ताव यह है कि pseudo-terminal (PTY) को बढ़ाकर उसमें JSON-RPC-आधारित out-of-band channel जोड़ा जाए
    मौजूदा escape sequences की सीमाएँ बहुत हैं।
    इस तरीके से क्रमिक और backward-compatible transition संभव होगी।
    LSP या MCP की तरह capability negotiation किया जा सकता है, और kernel को सिर्फ channel उपलब्ध कराना होगा

    • इस काम के लिए JSON उपयुक्त नहीं है। DER या SDSER जैसे binary formats ज़्यादा efficient हैं
    • आधुनिक तरीका यह है कि user-facing messages को stderr पर और machine-friendly JSON को stdout पर भेजा जाए
      इससे pipelines और redirection वैसे ही काम करते रहेंगे, और colored output भी बना रहेगा