मैं Windows Terminal का उपयोग कैसे करता हूँ – tmux और custom workflow के साथ बनाई गई बेहद शक्तिशाली terminal automation

• tmux, SSH, nvim, और शक्तिशाली search·automation scripts को मिलाकर एक अनोखा workflow बनाया गया है, जिससे remote server की files को GUI के बिना भी तुरंत browse, edit और search किया जा सकता है
• सिर्फ एक key combination से tmux की कई windows में filename auto-search और तुरंत open, file switching और buffer management तक सब कुछ shortcuts से किया जाता है
• VSCode की धीमी speed और key bind conflicts से असंतुष्ट होकर लेखक ने scripts के जरिए सभी operations को खुद एकीकृत किया
• regex, perl, tmux, nvim जैसे Unix tools के संयोजन से file path और line info को अपने-आप पहचानकर खोलने की सुविधा बनाई गई
• इसे खुद implement करने की प्रक्रिया बहुत जटिल है, लेकिन यह दिखाती है कि terminal की शक्ति और extensibility को किस हद तक बढ़ाया जा सकता है

---

मेरा अपना terminal इस्तेमाल करने का तरीका

• यह लेख terminal और tools को जोड़कर एक efficient development environment बनाने के अनुभव को साझा करता है
• यह प्रक्रिया आम तौर पर इतनी जटिल है कि इसके लिए वीडियो की ज़रूरत पड़ती है, इसलिए टेक्स्ट के साथ वास्तविक वीडियो भी जोड़ा गया है (वीडियो देखना ज़रूरी)
• वीडियो के कुछ चरण (0:11, 0:21, 0:41) ऐसे हैं जहाँ बहुत से लोग हैरान होकर पूछते हैं, "क्या यह सच में संभव है?"

वीडियो में terminal workflow का चरण-दर-चरण सारांश

• 0:00 : लैपटॉप पर Windows Terminal चलाना
• 0:02 : ctrl + shift + 5 shortcut से नया terminal tab खोलना, ssh के जरिए घर के desktop से कनेक्ट होना, और तुरंत tmux चलाना
• 0:03 : tmux में default shell zsh चलाना, prompt दिखाना और पूरी configuration को asynchronously load करना
• 0:08 : zoxide से हाल की directory को fuzzy search करके वहाँ जाना
• 0:09 : ripgrep command टाइप करना शुरू, zsh पुराने usage history के आधार पर auto-complete करता है, और ctrl + f से उसे accept किया जाता है
• 0:11 : ctrl + kf shortcut से tmux scrollback के पूरे हिस्से में filename search करना, और filenames नीले रंग में highlight होना
• 0:12 : n key को लगातार दबाकर search किए गए file list में मनचाही file को ढूँढना
• 0:21 : o key से चुनी गई file को default app (nvim) में खोलना, और tmux उसे नई window में चलाता है (सब कुछ अब भी remote server पर चल रहा होता है)
• 0:26 : rust-analyzer से code के कई references पर जाने की कोशिश, कुछ macros पहचाने नहीं जाते, फिर 0:32 पर सही तरह से jump सफल होता है
• 0:38 : ctrl + kh से tmux focus को बाईं window में ले जाना
• 0:39 : n key को फिर दबाकर "copy-mode" स्थिति में पिछले file search results को आगे भी browse करना
• 0:41 : o key से इस बार दूसरी file को पहले से खुले nvim instance में खोलना
• 0:43 : b key से खुले हुए file buffers की list देखना, और दो files के बीच बारी-बारी से switch करके समाप्त करना

यह terminal workflow इस्तेमाल करने की नौबत क्यों आई?

• VSCode धीमा था, और खासकर vim plugin के साथ बहुत lag करता था
  • editor, vim plugin, terminal और window management features के बीच key bind conflicts बार-बार होते थे, जो असुविधाजनक था
  • Zed editor भी आज़माया गया, लेकिन उस समय वह अभी अपरिपक्व था और key bind conflict की समस्या वहाँ भी बनी रही
• nvim (Neovim) को terminal में सीधे इस्तेमाल करना शुरू किया, लेकिन
  • ripgrep आदि से search किए गए filenames को हर बार copy करके editor में paste करना बहुत झंझट वाला था
  • खासकर जब ripgrep results में filename और line number साथ आते थे,
    • paste करते समय हर बार syntax error हो जाती थी
    • और असल में file खोलने से पहले ही अनावश्यक editing करनी पड़ती थी
  • लेखक को लगा कि VSCode के ctrl-click जैसा ऐसा workflow चाहिए जो file path को सीधे खोल सके
• इसलिए tmux का उपयोग करके मनचाहा feature खुद implement किया गया
  • जब लोग पूछते हैं कि tmux क्यों इस्तेमाल करते हैं, तो लेखक कहता है कि यही automation और session persistence उसकी वजह है
  • terminal कल्पना से कहीं अधिक शक्तिशाली है, लेकिन सिर्फ default features से इस तरह की automation सामने नहीं आती
  • tmux भले पुराना हो, इसकी syntax जटिल हो और bugs भी हों, फिर भी extensibility और customization की क्षमता के कारण इसे चुना गया

मुख्य implementation तरीके

tmux में पूरे scrollback से filename search

• tmux copy-mode में जटिल regular expression से filename patterns match करना
• खुद बनाए गए regex script (search-regex.sh) से file path, line और column तक highlight करना
• उदाहरण tmux config:

  bind-key f copy-mode \; send-keys -X search-backward '정규표현식'  
  

चुनी हुई file को नई window/मौजूदा window में खोलना

• tmux shortcut के जरिए चुनी हुई file को default app या editor (nvim आदि) में खोलने के लिए custom behavior बनाना
• relative path support और tilde expansion शामिल

  bind-key -T copy-mode-vi o  send-keys -X copy-pipe 'cd #{pane_current_path}; ...'  
  bind-key -T copy-mode-vi O  send-keys -X copy-pipe-and-cancel 'tmux send-keys ...'  
  

पहले से खुले nvim instance में file खोलना

• perl script के जरिए tmux किसी खास nvim pane को ढूँढता है और उसी pane में file/line info तक सीधे key input भेजता है
• file:line:column syntax को vim command में बदलकर अपने-आप open किया जाता है

इस तरीके के फायदे और सीमाएँ

• local terminal की functional limitations से आगे निकलना: tmux के जरिए remote server पर files को स्वतंत्र रूप से browse/edit/search करना
• भले editor remote editing protocol को support न करे, workflow वही रखा जा सकता है
• सभी key binds, search, file switching, buffer management आदि को पूरी तरह अपनी पसंद के अनुसार एकीकृत करना
• VSCode plugin बनाने की तुलना में automation को अधिक तेज़ी और आसानी से बनाना
• खुद लिखी गई scripts आसानी से टूट सकती हैं और maintain करना कठिन है, इसलिए दूसरों को recommend करना मुश्किल है

वैकल्पिक समाधान

• आम तौर पर recommend की जाने वाली open source/tools की combinations:
  • fish + zoxide + fzf: fuzzy directory, command search, और कुछ file search workflows का विकल्प बन सकते हैं
  • editor के built-in features (tabs, windows, fuzzy finder आदि) भी अधिकांश users के लिए पर्याप्त हैं
  • qf: terminal output से file selection कर सकता है, लेकिन interactive tools के साथ integrate नहीं हो सकता, vi-like CLI का उपयोग करता है
  • e: file:line path को पहचानने वाला एक छोटा tool (हर editor type के लिए अलग script चाहिए)
  • vim --remote, code filename, emacsclient आदि भी मिलते-जुलते असर देते हैं, लेकिन file:line पहचान अब भी अधूरी है

निष्कर्ष और सीख

• terminal कल्पना से कहीं अधिक शक्तिशाली है, और scripts के जरिए इसे जोड़कर GUI tools में असंभव automation भी बनाई जा सकती है
• लेकिन maintainability, scripts में छिपे bugs जैसी practical सीमाएँ भी मौजूद हैं
• अगर terminal workflow automation में रुचि है, तो custom tmux/nvim/fzf environment से चरणबद्ध तरीके से शुरुआत करना सबसे व्यावहारिक है

[GN⁺]

Hacker News राय

• मैं भी लगभग ऐसा ही ट्रिक इस्तेमाल करता हूँ। tmux scrollback का उपयोग करता हूँ, और tokenized output को zsh में pipe करता हूँ ताकि tmux स्क्रीन पर दिख रही हर चीज़ के लिए autocomplete इस्तेमाल कर सकूँ। संबंधित Threads पोस्ट और gist code भी शेयर किया है। यह मेरे लिए सच में बहुत उपयोगी रहा

• मुझे इस तरह का workflow बहुत पसंद है, और मैं भी कई सालों से कुछ ऐसा ही बार-बार सुधारता आ रहा हूँ। समय के साथ मैं custom layers को जितना हो सके उतना कम करने की कोशिश कर रहा हूँ, क्योंकि overlays जितने बढ़ते हैं, maintenance cost उतनी बढ़ती है। plain Vim में भी (अलग tmux के बिना) पोस्ट में बताई गई ज्यादातर चीज़ें की जा सकती हैं, जैसे rg --vimgrep restore_tool | vim -c cb - (vim -c cb - Vim की मेरी सबसे पसंदीदा सुविधाओं में से एक है, और यह देखकर हैरानी होती है कि लोग इसे लगभग इस्तेमाल ही नहीं करते)। बेशक हर बार rg search फिर से चलाना भारी पड़ सकता है, इसलिए मैं आमतौर पर terminal में results का विश्लेषण करता हूँ और ज़रूरत पड़ने पर tmux custom command से last command का output कॉपी करके vim में भेज देता हूँ। इस दौरान मैं prompt में Unicode characters इस्तेमाल करने वाला ट्रिक भी कभी-कभी उपयोग करता हूँ, और tmux saveb - | vim -c cb - से भी भेज देता हूँ

  • 10 साल पहले मैंने बहुत बड़े multi-file, multi-package vim setup को छोड़ दिया था, और अब हर साल लगभग 1–2 lines जोड़कर बहुत simple vimrc बनाए रखते हुए लगातार चीज़ें सरल कर रहा हूँ। पुराने software की default settings के पीछे आमतौर पर कोई वजह होती है, इसलिए उन्हें यूँ ही बदलने के बजाय पहले वह वजह समझने की सलाह दूँगा
  • (आपने कहा कि vim -c cb - Vim में आपकी पसंदीदा सुविधा है—क्या आप बता सकते हैं कि यह करता क्या है? ls | vim - और ls | vim -c cb - चलाने पर मुझे तुरंत फर्क समझ नहीं आता)
  • क्या यह 'vim -q <(ripgrep --vimgrep restore_tool)' जैसी ही किसी चीज़ के लिए है?

• यह setup अच्छा लग रहा है क्योंकि इसमें tmux, fzf, rg, zoxide, और साफ-सुथरा nvim सब शामिल हैं। अगर नहीं है, तो मैं atuin, starship, bat, glow, duf, dogdns, viddy, gum/sesh, dust, btop वगैरह भी recommend करना चाहूँगा। ये सब GitHub की Awesome Terminal XYZ lists में मिल जाएँगे। atuin तो लगभग must-have है, और अगर zoxide नहीं है तो ऐसा लगता है जैसे आप athlete हों लेकिन जूते ठीक से फिट न हों। terminal videos रिकॉर्ड करने के लिए asciinema बेहतर विकल्प है। सच कहें तो पहले ऐसे setup को ही “programmer” कहा जाता था। आजकल VSCode, Zed, Cursor जैसे tools भी ज़रूरी हैं, और किस LLM को क्या काम देना है यह भी पता होना चाहिए। ये tools अब नया “minimum” हैं, लेकिन पुराने environment की जगह नहीं लेते। चाहे Claude Code या gptel को कितनी भी अच्छी तरह इस्तेमाल कर लो, कभी-कभी वे tree बिगाड़ सकते हैं, और magit के बिना git इस्तेमाल करना मैं सोच भी नहीं सकता। अगर किसी को सच में लगता है कि plain Cursor से वह OP से तेज़ है, तो मैं कहूँगा कि वह LLM को असली काम में इस्तेमाल करते हुए एक वीडियो रिकॉर्ड करके दिखाए

  • programmer होना सिर्फ dev environment setup का नाम नहीं है। कुछ मशहूर programmers ex editor पसंद करते हैं, और कुछ beginners के पास भले ही चमकदार IDE हो, पर बुनियादी समझ की कमी रहती है। हाँ, अच्छे tools मदद कर सकते हैं, लेकिन असली सफलता पर उनका असर अक्सर छोटा ही रहा है। LLM शायद इसे बदल दे, पर अभी कहना जल्दबाज़ी होगी। उदाहरण के लिए, अगर running shoes ठीक फिट न होने से आप 5% धीमे हो जाते हैं, तब भी startup में सफलता और असफलता का फर्क ऐसी छोटी चीज़ें नहीं तय करतीं। वजह ज़्यादातर cofounder conflict, motivation loss, या product-market mismatch जैसी बड़ी समस्याएँ होती हैं
  • आपकी tool list अच्छी है, लेकिन जो लोग atuin, dogdns, btop जैसे ज्यादातर tool names नहीं जानते, उनके लिए यह थोड़ा अपरिचित लग सकता है
  • command list मुझे बहुत पसंद आई। मैं इसमें fd (लेखक: sharkdp) भी ज़रूर जोड़ूँगा। यह find का replacement है और usability के लिहाज़ से शानदार है। और atuin तो मेरी CLI life का सबसे बड़ा upgrade रहा है। 6 महीने पहले चलाया गया कोई rare command भी इससे बहुत आसानी से मिल जाता है
  • ऐसा लगता है कि tools के चुनाव पर कुछ ज़्यादा ही ध्यान है। सच में अच्छे developers bare environment में भी जल्दी output दे देते हैं। हाँ, अच्छे tools थोड़ा-बहुत मदद कर सकते हैं, लेकिन ज़्यादातर यह व्यक्तिगत मज़ा और पसंद का मामला है। अगर आपको सच में लगता है कि आपकी productivity IDE पर बहुत निर्भर है, तो शायद इसका मतलब है कि सीखने और आगे बढ़ने का सफ़र अभी लंबा है। पहले भी “tools जानना = programmer” जैसी कोई बात नहीं थी। मैंने जितने बेहतरीन developers देखे हैं, उनमें से अधिकांश more/grep/vi और थोड़ी सोच के दम पर शानदार नतीजे निकालते थे। value creation आखिरकार सोच से आती है। LLM के दौर में भी यह बात सही है

• लगभग हर vim/tmux user ने शायद आधा-buggy लेकिन तेज़ unofficial “emulation Emacs” खुद बना लिया होगा

  • मैंने तो ऐसा terminal emulator भी बना लिया जिसमें tmux का two-key prefix हटाकर सारे commands के लिए एक single ctrl-modified key कर दिया। project link
  • मैं vim/tmux और emacs दोनों इस्तेमाल करता हूँ (और पहले लंबे समय तक सिर्फ emacs ही इस्तेमाल किया), और मेरा emacs environment कहीं ज़्यादा ad-hoc, कम documented और ज़्यादा buggy था। इसके मुकाबले vim+tmux setup अपेक्षाकृत स्थिर है
  • इस बात से मैं गहराई से सहमत हूँ। मैं अभी अपने workflow में nvim के अंदर :Term चलाता हूँ
  • vim+tmux environment pipes, files, signals, scrollback जैसे system primitives पर बहुत निर्भर करता है। इसलिए यह अलग-अलग tool environments, ssh, और restricted shells में भी स्वाभाविक और transparent तरीके से काम करता है। portability और debugging में यह बहुत बड़ा फ़ायदा है। यानी इन बुनियादी guarantees के ऊपर मेरा workflow आसानी से टुकड़ों में बँट सकता है, इसलिए अपनी vim config खुद बनाना मुझे बहुत स्वाभाविक चुनाव लगता है

• वह Windows पर tmux इस्तेमाल करता है, लेकिन असल में कैसे करता है यह समझ नहीं आया। कोई समझा सके तो अच्छा होगा

  • मेरा अनुमान है कि वह Unix system में remote login करके असली काम करता है। Unix server पर tmux पूरी तरह चल सकता है। मैं भी कभी-कभी VirtualBox VM में SSH करके WSL से अधिक साफ़ compatibility layer इस्तेमाल करता हूँ। इसी वजह से tmux दूसरी विधियों से बेहतर ठहरता है। अगर server पर install है, तो remote होकर भी वह अपना पूरा काम करता है। संबंधित व्याख्या लिंक

• इस तरह workflows शेयर करना मुझे बहुत पसंद है। target audience के लिए यह बिल्कुल सही है। मुझे बस लगा कि वीडियो में आवाज़ होती तो अच्छा होता, लेकिन बाद में action list पढ़ लेना भी ठीक था। मुझे अपने workflow के लिए भी कुछ उपयोगी बातें सीखने को मिलीं। उसने tmux के मुश्किल keyboard shortcuts का ज़िक्र किया था—क्या यहाँ किसी ने byobu इस्तेमाल किया है? byobu, tmux का wrapper है, जो ज़्यादातर commands को F# keys पर map कर देता है। मैंने इसे 10 साल पहले पहली बार इस्तेमाल किया था और तब से लगातार इस्तेमाल कर रहा हूँ। उससे पहले कुछ साल pure tmux ही इस्तेमाल किया था

  • यह जानकर खुशी हुई कि content आपको दिलचस्प लगा :) मैंने इसे जितना हो सके उतना स्पष्ट और एक नज़र में समझ आने वाला बनाने की कोशिश की। मैं tmux shortcuts में से ज़्यादातर remap करके इस्तेमाल करता हूँ। ctrl-k मेरा prefix है, और h “बाएँ pane चुनो” वाला default नहीं है। byobu मैंने इस्तेमाल नहीं किया, लेकिन विवरण से लगता है कि वह बस default shortcuts को थोड़ा सुविधाजनक बनाता है, इसलिए मुझे नहीं लगता कि मैं उस पर कुछ और layer जोड़ना चाहूँगा

• इस तरह बिना बड़े regex के भी tmux plugins से copy mode जैसी सुविधाएँ बढ़ाई जा सकती हैं। tmux-fpp, tmux-copycat, tmux-fingers, tmux-urlview जैसे विकल्प हैं। speed के लिहाज़ से built-in features पर ज़्यादा निर्भर रहना फायदेमंद हो सकता है, इसलिए ध्यान देने लायक है। मुझे खास तौर पर tmux-resurrect (session save/restore), tmux-continuum (automation features), और Oh-My-Fish के लिए tmux-zen भी बहुत पसंद हैं। tmux-resurrect, tmux-continuum, tmux-zen साझा कर रहा हूँ। ज़ोर देकर कहूँगा कि शानदार tmux environment सेट करना जितना लगता है उससे कहीं ज़्यादा आसान है

  • मैंने भी tmux-copycat से original regex लिया था। लेकिन a) वह regex : को ठीक से capture नहीं करता, और b) copycat अपनी viewer abstraction इस्तेमाल करता है, इसलिए एक search पर सिर्फ एक ही action किया जा सकता है। मेरी विधि tmux की built-in search को reuse करती है, इसलिए highlighted files पर आप अपनी पसंद के actions freely bind कर सकते हैं। ज़्यादातर plugins सिर्फ copy/paste support करते हैं या अपना mode चढ़ा देते हैं, क्योंकि tmux highlight control लगभग सिर्फ built-in search के लिए ही उपलब्ध कराता है

• यह setup वाकई खूबसूरत है। लेकिन यह अब भी रहस्य है कि terminal में अभी तक proper AI typeahead क्यों नहीं आया। Cursor tab इसके लिए बिल्कुल सही लगता है, लेकिन terminal integration अटका हुआ है। मन करता है कि अस्थायी तौर पर terminal output को fake file में pipe करके cursor को भेजने वाला कोई product झटपट बना दूँ

• लेख का शीर्षक असल में "How I use my terminal" है

  • HN की automatic सुविधा title का पहला शब्द अगर How हो तो उसे काट देती है। इसका कोई खास आधार नहीं है; admin इसे clickbait रोकने के लिए बताते हैं, लेकिन व्यवहार में यह सिर्फ उलझन पैदा करता है
  • पहले मुझे लगा यह पोस्ट फ़िल्म 'There Will Be Blood' की parody जैसी कुछ है (क्योंकि अभी title 'I use my terminal' दिख रहा है)
  • मुझे भी पहले लगा था कि यह किसी के खुद बनाए हुए terminal emulator के इस्तेमाल का लेख है
  • मुझे भी अब यह समझ आया। पोस्ट को स्किम करने पर लगा कि पूरा शीर्षक शायद "I use my terminal (and so should you )" जैसा होगा। terminal पर लेख हमेशा अच्छे लगते हैं, और Chromebook user होने के नाते मेरे लिए browser और terminal ही काफी रहे हैं। Mac पर जाने पर चीज़ें बहुत फैल जाती हैं, इसलिए मैं आमतौर पर terminal या browser ही इस्तेमाल करता हूँ
  • HN पर title submit करते समय आमतौर पर कुछ सामान्य prefix या suffix अपने आप हटा दिए जाते हैं