हो सकता है कि आपको tmux की सच में ज़रूरत न हो: डेवलपमेंट वर्कफ़्लो में tmux का विकल्प कैसे अपनाएँ
(bower.sh)- लंबे समय तक tmux इस्तेमाल करने के बाद, हाल में इसकी जटिलता और सीमाओं (color compatibility, scrollback, mouse copy, protocol support की कमी आदि) को लेकर संशय महसूस हुआ
- सेशन persistence (detach/attach) या window split/management जैसी tmux की मुख्य क्षमताएँ सिर्फ tmux से ही संभव हों, ऐसा ज़रूरी नहीं है
- dtach, abduco, shpool जैसे Unix दर्शन वाले हल्के टूल्स का उपयोग करके, सिर्फ सेशन management पर ध्यान रखते हुए भी native scrollback और simplicity हासिल की जा सकती है
- खासकर
shpool+ ssh संयोजन के ज़रिए कई remote sessions को सीधे window manager से manage करते हुए, native सुविधाएँ (notifications, scroll, titles आदि) वैसे की वैसी इस्तेमाल की जा सकती हैं - यह परफेक्ट नहीं है, लेकिन लेखक के लिए यह tmux का पूरी तरह विकल्प बन सका, और सरल तथा आसानी से maintain होने वाला workflow संतोषजनक लगा
tmux के फायदे और नुकसान
- सेशन बनाए रखना (detach/attach), window management (tabs, split) आदि पहले से ही वर्कफ़्लो का मुख्य हिस्सा थे, जो tmux देता था
- लेकिन सही
TERMसेटिंग न होने पर color rendering की समस्या, और terminal व tmux के बीच interaction का ध्यान रखना पड़ना, जटिलता बढ़ा देता है - scroll buffer का उपयोग भी tmux के अलग तरीके का अभ्यस्त होने की मांग करता है, और mouse से क्षेत्र copy करना भी splits वाले माहौल में असुविधाजनक था
- kitty graphics protocol जैसी नई terminal features के समर्थन की कमी, और experimental protocol support न होने की समस्या भी मौजूद है
- escape code की दोबारा व्याख्या और session/window जैसी अवधारणाएँ थोपने के कारण multiplexer को terminal ecosystem की प्रगति में बाधा मानने वाली आलोचना भी है
tmux के विकल्पों की खोज
- सेशन persistence:
- साधारण तौर पर
ctrl-z+fg,nohup,disownजैसे तरीके हैं, लेकिन ये पूरी तरह विकल्प नहीं बनते - सिर्फ सेशन बनाए रखने के उद्देश्य वाले कई टूल्स (
dtach, abduco, shpool) सामने आए हैंfork()और UNIX socket के संयोजन से daemon और client के बीच कनेक्शन बनता है- tmux के विपरीत, virtual split के बिना native scrollback मिलता है, और कुछ में buffer restore की सुविधा भी है
- उपयोग अनुभव के अनुसार, ज़्यादातर विकल्पों में bugs हैं और
nvimके भीतर detach key combination के काम न करने जैसी वजहों से परिपक्वता कम लगी - shpool ही detach/attach commands और keymap customization के लिहाज़ से सबसे अधिक परिपक्व लगा
- साधारण तौर पर
- window management:
- local में window manager से split और layout manage किए जाते हैं
- remote (SSH) वातावरण में भी ssh_config और shpool के संयोजन से कई sessions को अलग-अलग windows में स्वतंत्र रूप से बनाए रखा जा सकता है
- autossh के साथ मिलाकर network reconnect की स्थिति में भी session बनाए रखे जा सकते हैं
नया workflow
- व्यक्तिगत रूप से ghostty (laptop), sway+foot (personal PC) से window management किया जाता है। server Proxmox-आधारित headless VM हैं, जहाँ हमेशा SSH development environment बना रहता है
- कई shpool sessions को ssh shortcuts से अपने-आप जोड़ा जाता है, और local window manager में स्वतंत्र रूप से नियंत्रित किया जाता है
ssh_configमें हर host के लिए shpool session attach को automate किया गया है- हर terminal में IRC, dotfiles management, अलग neovim environment आदि के लिए multiple sessions में अलग-अलग access संभव है
- native scroll, notifications, terminal titles जैसी वे सुविधाएँ, जिन्हें tmux अस्थिर रूप से support करता था, अब उल्टा अधिक स्वाभाविक ढंग से काम करती हैं
- कुछ कमियाँ भी हैं: vim से दोबारा जुड़ने पर terminal state restore में देरी, और
nvimइस्तेमाल करते समय resize की समस्या- multiplayer support नहीं है (कई clients से autossh एक साथ होने पर session conflict)
- फिर भी, व्यक्तिगत उपयोग के आधार पर tmux का पूर्ण विकल्प सफल रहा
निष्कर्ष
- पूरी तरह वही अनुभव नहीं है, लेकिन tmux की जटिलता और सीमाओं से निकलकर अधिक सरल और लचीले session management workflow में बदला जा सकता है
- अपने-अपने workflow के अनुसार shpool जैसे वैकल्पिक टूल्स पर विचार किया जा सकता है
7 टिप्पणियां
आजकल AI से tmux जैसी चीज़ें बनवाकर इस्तेमाल करते हैं। Xterm.js + react + electron से 3-4 घंटे में ऐसी 100 चीज़ें भी निकाल सकते हैं, और ज़रूरत पड़े तो रियल-टाइम में बदलकर इस्तेमाल भी कर लेते हैं—कुछ वैसा एहसास जैसे शाबू-शाबू में जो खाना हो वह डाल दो, और source में भरपूर डाल दो।
मैं इसे आराम से wezterm के साथ इस्तेमाल कर रहा हूँ
Screen सबसे बढ़िया!
cargo install shpool... बस tmux ही इस्तेमाल करूँगा... हर OS के लिए अलग-अलग package होने चाहिए!Zellij जैसा एक बेहतरीन नया विकल्प है। इसकी ज़ोरदार सिफारिश करता हूँ।
Zellij - डेवलपर & Ops के लिए टर्मिनल
यह भी मैंने काफ़ी पहले पोस्ट किया था, हाहा
Hacker News की राय
यह लेख Linux-on-the-Desktop उपयोगकर्ताओं के लिए है, लेकिन मैं यह ज़रूर कहना चाहूँगा कि tmux MacBook पर iTerm2 के साथ इस्तेमाल करने पर वास्तव में अपनी पूरी चमक दिखाता है
iTerm2 की tmux integration की वजह से मेरे workflow में tmux पूरी तरह स्वाभाविक रूप से घुल-मिल गया है
अगर
~/.ssh/configमें नीचे की तरह सेटिंग कर दें, तो MacBook को दोबारा चालू करने या network बदलने के बाद भी कभी भी ssh tmux के जरिए remote development server तक आसानी से पहुँचा जा सकता हैiTerm2 और tmux integration की वजह से remote tmux tabs और scroll buffer लगभग local tabs की तरह काम करते हैं, और सच कहूँ तो tmux commands जाने बिना भी इसे इस्तेमाल किया जा सकता है
मैं अपने सभी personal devices पर Linux इस्तेमाल करता हूँ, और काम के लिए ज़्यादातर MacBook चलाता हूँ, इसलिए tmux platform-independent तरीके से वही environment दोबारा बना देता है, जो बहुत उपयोगी है
Linux पर मैं Alacritty इस्तेमाल करता हूँ, लेकिन macOS पर सही config या window/scroll से जुड़ी differences की वजह से हमेशा कुछ न कुछ तुरंत ठीक से काम नहीं करता
मैं OS differences पर समय बर्बाद नहीं करना चाहता, इसलिए tmux और iTerm2 का combination लेकर Linux जैसा लगभग वही अनुभव पा लेना बेहतर लगता है
session के भीतर अलग scrollback मिलना भी मेरे लिए एक फायदा है
tmux पर की जाने वाली आलोचना मुझे ज़्यादा terminal developers से जुड़ा मुद्दा लगती है
अगर support कमज़ोर है, तो बस ऐसे terminal पर चले जाइए जो बेहतर support देता हो
मैं mosh और screen का combination इस्तेमाल कर रहा हूँ
server reboot हो जाए तब भी session restore हो सकता है, और network बदलने पर भी session disconnect नहीं होता
संदर्भ: Immortal SSH Sessions
मैंने tmux को दर्जनों बार आज़माया, लेकिन वह कभी खास पसंद नहीं आया, इसलिए हमेशा screen पर लौट गया
लेकिन यह tip देखने के बाद इसे एक बार फिर आज़माने का मन हुआ है
vim, tmux और iTerm2 के combination में मुझे अक्सर colors और fonts की समस्या आती रही, इसलिए आखिरकार local पर tmux छोड़ना पड़ा
updates के बाद भी टिके रहना और session persistence से जो फायदा मिलता था, वह इतना बड़ा नहीं था
अगर font की समस्या सुलझ जाए तो मैं इसे फिर से आज़माने को तैयार हूँ, लेकिन अभी समय नहीं है
क्या Linux terminals में iTerm2 जैसा कोई ऐसा विकल्प है जो tmux integration देता हो?
मैं अभी भी GNU Screen इस्तेमाल कर रहा हूँ, लेकिन tmux को फिर एक बार इस्तेमाल करने के लिए तैयार हूँ
इस blog post को देखकर मुझे फिर याद आया कि मैं tmux क्यों इस्तेमाल करता हूँ
लोग tmux जैसा workflow बनाने के लिए इतनी ज़्यादा मेहनत कर रहे हैं कि सीधा tmux इस्तेमाल करना कहीं बेहतर लगता है
कभी-कभी copy-paste थोड़ा असुविधाजनक होता है, लेकिन मुझे उससे ज़्यादा फर्क नहीं पड़ता
'multiplexer बेकार overhead पैदा करता है' वाली आलोचना ऐसी चीज़ है जिसकी परवाह आपको codebase maintainer न होने पर करने की ज़रूरत नहीं है
copy-paste की समस्या सिर्फ tmux की नहीं है
vim जैसे apps जो पूरे terminal को खुद draw करते हैं, उनमें यह समस्या हो सकती है
OSC52 नाम की terminal escape sequence से यह समस्या आसानी से हल की जा सकती है
नीचे जैसा कोई सरल Python script इस्तेमाल करें, तो grep results जैसी चीज़ें भी सीधे system clipboard में भेजी जा सकती हैं
tmux और nvim पहले से OSC52 support करते हैं, और इसे दूसरी जगहों पर भी आसानी से इस्तेमाल किया जा सकता है
वैसे, मैंने tmux में एक PR submit किया था, और maintainer Nick Marriott का communication मुझे बहुत अच्छा लगा
code भी काफ़ी व्यवस्थित है, और tmux उससे बेहतर हुआ
ऐसी चर्चाओं से थक गया हूँ जो जैसे किसी गैर-मौजूद समस्या को ज़बरदस्ती बना रही हों
लेखक के दिए कारण मुझे बिल्कुल convincing नहीं लगे, बल्कि उसका "7 साल से ज़्यादा tmux इस्तेमाल करने का अनुभव" भी थोड़ा संदिग्ध लगा
मुझे कुछ हफ़्ते पहले ही Tmux के बारे में पता चला, और किसी खास pane में programmatically key input भेजने की इसकी scripting capability से मैं बहुत प्रभावित हुआ
जापानी forum से प्रेरित होकर मैंने सोचा कि क्या Claude Code (आगे CC) interactive CLI scripts के साथ सीधे interact कर सकता है, और मैंने पुष्टि की कि Tmux के ज़रिए यह संभव है
इसलिए मैंने claude-code-tools नाम का एक छोटा tool बनाया, जिससे CC जैसे CLI agents Tmux panes बना सकें, उनके भीतर scripts चला सकें, और real-time interaction भी कर सकें
यह कुछ-कुछ Playwright या Puppeteer के terminal version जैसा है
claude-code-tools GitHub लिंक
इस तरीके से CC interactive CLI scripts की automated testing कर सकता है, किसी दूसरे pane में UI खोलकर Puppeteer MCP से browser में testing कर सकता है, debugger चालू करके breakpoints पकड़ सकता है, multi-agent integration कर सकता है, और भी बहुत कुछ
सोचता हूँ कि क्या tmux के alternatives भी इस तरह की extensibility दे सकते हैं
जानकारी के लिए, screen में भी
stuffcommand के जरिए pane में programmatically key input भेजा जा सकता हैइस तरीके से Claude Code Gemini CLI, OpenCode जैसी अलग-अलग CC instances को interactive mode में control कर सकता है
इससे traditional sub-agents से अलग तरह का integration संभव होता है
सोचता हूँ कि tmux-cli wrapper वास्तव में results बेहतर करता है या नहीं
मैं तो बस Claude से कहता हूँ कि existing tmux commands इस्तेमाल करे, और वह ठीक काम करता है, इसलिए मैं Bash अलग से इस्तेमाल नहीं करता और सारे commands tmux session के भीतर ही चलवाता हूँ
अगर आप यह सब terminal स्तर पर और आसान बनाना चाहते हैं, तो Kitty का remote control feature भी शानदार है
Kitty Remote Control परिचय
terminal मूल रूप से सिर्फ file descriptors ही है, इसलिए script(1), expect(1), chat(8) जैसे मिलते-जुलते tools 80 के दशक से मौजूद हैं
tmux अनिवार्य नहीं है
अगर tmux में TERM setting सही न हो, तो colors वगैरह ठीक से render नहीं होते; यही समस्या सभी terminal emulators/programs में भी होती है
Unix और Linux systems में TERM और terminfo/termcap की अवधारणा ही मूलभूत है, इसलिए सही setting अनिवार्य है
यह tmux की कोई unique समस्या नहीं है
लेकिन अफ़सोस है कि लेखक इसका दोष tmux पर डाल रहा है
scroll की समस्या भी क्या सच में tmux की अपनी समस्या है, इस पर संदेह है; tmux alternate screen buffer इस्तेमाल करता है, जिसे viewport baseline साफ़ रखने और cursor movement आसान बनाने के लिए लाया गया था
ज़्यादातर modern terminals alternate screen की स्थिति में भी local scroll की अनुमति देते हैं, इसलिए यह व्यवहार वैसे लागू नहीं रह पाता
ज़्यादातर programs भी अगर default settings सही न हों, तो मनचाहे तरीके से काम नहीं करते
tmux में असुविधा यह है कि तुरंत यह साफ़ नहीं होता कि 'क्यों' दिक्कत हो रही है, लेकिन समाधान क्या होना चाहिए यह भी स्पष्ट नहीं है (जैसे default को 256colors करना चाहिए?)
बात सही है, लेकिन tmux इस्तेमाल करते समय एक अतिरिक्त layer जुड़ जाती है जिस पर ध्यान देना पड़ता है
tmux के अंदर tmux-विशेष TERM इस्तेमाल करना चाहिए, और बाहर अपने terminal के मुताबिक TERM सेट करना चाहिए
सिर्फ tmux FAQ देख लें तो display समस्याओं का बड़ा हिस्सा TERM के गलत या missing setting से आता है
"multiplexer बेकार overhead देता है" वाली बात मेरे लिए उल्टा tmux पसंद करने की वजह है
जब ज़्यादा apps termcap support छोड़ते जा रहे हैं, tmux होने पर मैं अपने VT520 जैसे पुराने terminal पर भी apps चला सकता हूँ
किसी terminal developer को tmux पसंद है या नहीं, मुझे उससे कोई खास मतलब नहीं
आखिरकार user के नज़रिए से architectural elegance से ज़्यादा ज़रूरी है कि चीज़ काम करे
वैसे व्यक्तिगत रूप से मुझे alacritty बेहतर लगता है (हालाँकि मैं ज़्यादातर Konsole इस्तेमाल करता हूँ)
बस यह कह देना चाहता हूँ कि आपके पास VT520 है, यह सुनकर ईर्ष्या हो रही है
मैं लंबे समय से VT525 ढूँढ रहा हूँ, लेकिन वह महँगा भी है और ज़्यादातर sellers विदेश में हैं
मुझे हमेशा यह जानने की जिज्ञासा रही है कि genuine VT525 पर nosh realizer ठीक से चलता है या नहीं
tmux न भी रहे, तो subtle TERM incompatibility वाले apps को दूसरे तरीक़े से transliterate किया जा सकता है
मेरा VT420 hardware flow control support नहीं करता, इसलिए मुझे software flow control इस्तेमाल करना पड़ता है, और यह तरीका आजकल के terminal apps के साथ खास compatible नहीं है
GNU Screen इसका बहुत अच्छा समाधान साबित हो रहा है, और इसके अलावा भी कई features देता है
tmux मैंने modern emulators में बहुत इस्तेमाल किया है, लेकिन पुराने terminals पर इसमें यह अहम flow-control feature कमज़ोर लगता है
termcap/terminfo support न करने वाले apps से निपटने के लिए tmux उपयोगी है, इस बात से मैं सहमत हूँ
जानना चाहता हूँ कि आपको alacritty बेहतर क्यों लगता है
पुराने hardware पर इसकी startup speed धीमी है, tab जैसी practical features भी कम हैं, और benchmarks में भी यह kitty/ghostty/konsole/foot से पीछे है
फिर भी यह दिलचस्प है कि किसी न किसी कारण लोग alacritty इस्तेमाल करते रहते हैं
मैं अभी भी tmux इस्तेमाल करने वाला हूँ
अलग-अलग projects के बीच session management और reboot के बाद session recovery आसान होने की वजह से यह मुझे पसंद है
mouse copy/paste के मामले में tmux-yank के साथ मुझे कभी कोई समस्या नहीं हुई
मैं कई सालों से वही environment इस्तेमाल कर रहा हूँ
tmux के send-keys feature से मैंने dotfiles refactor करते समय कई panes/sessions में एक साथ alias या config files update करना और nvim restart करना automate किया है
इस अनुभव को मैंने blog और video में समेटा है
मैं "you might not need tmux" को "you might not need browser tabs" वाली बहस जैसा मानता हूँ
अगर आपके पास एक-दो terminal sessions या web pages ही हों, तो शायद इसकी ज़रूरत न पड़े; लेकिन उससे ज़्यादा होने पर window management इतना असुविधाजनक हो जाता है कि अंत में आप वही functionality फिर से खुद बनाने लगते हैं
आजकल मैं बस अपने window manager की window management capabilities का पूरा फायदा उठाने की कोशिश करता हूँ
browser tabs, terminal tabs या tmux की जगह अगर window placement, tab management और bookmarks window manager संभाल ले, तो मुझे असुविधा नहीं होती
अब मेरा विश्वास लगभग यह हो गया है कि tabs की ज़िम्मेदारी application की नहीं, window manager की होनी चाहिए
मेरा window manager windows को tile कर सकता है, या overlapping windows को tabbed groups में बदल सकता है
ये tabs एक ही app की हों या अलग-अलग apps की, कोई फर्क नहीं पड़ता
browser tabs को अलग windows में आसानी से तोड़ा या फिर जोड़ा जा सकता है, लेकिन tmux tabs इस मामले में उतनी flexible नहीं हैं
एक अच्छा window manager tabs और windows को मनचाहे तरीके से फिर से जोड़-तोड़ सकता है
मेरी tmux config में clickable tabs हैं
MS Windows का multi-window management (Alt Tab, Win Tab आदि) बहुत शानदार है
हर terminal को अलग icon/background color देकर पहचानना आसान हो जाता है, और operating system खुद window management का बड़ा हिस्सा संभाल लेता है
मैंने Mac भी इस्तेमाल किया है, लेकिन इस मामले में वह Windows जितना संतोषजनक नहीं लगा
buffer scrollback जैसी tmux से जुड़ी जिन बातों की लोग शिकायत करते हैं, वही बातें मेरे लिए tmux इस्तेमाल करने की प्रेरणा हैं
मेरा दूसरा laptop पुराना debian terminal-only setup है, उसमें mouse नहीं चलता, इसलिए copy/paste सिर्फ tmux के जरिए ही संभव है
मेरे लिए tmux का कोई विकल्प नहीं है
tmux capture-pane - | vim -का combination कभी-कभी mouse scroll wheel से भी ज़्यादा सुविधाजनक होता हैsuckless समूह terminal design में जान-बूझकर tmux जैसी features implement न करने का बिल्कुल उल्टा दृष्टिकोण अपनाता है
संदर्भ: st.suckless.org/goals
उम्मीद है Kitty सफल हो, क्योंकि उसमें terminal emulator के भविष्य को आगे ले जाने की क्षमता लगती है
लेकिन मैं Kitty को काम के लिए इस्तेमाल नहीं कर सकता, और tmux के बिना session, window layout, state, copy buffer, scrollback सब खो जाएगा, इसलिए मैं इसे बिल्कुल नहीं छोड़ सकता
Windows पर कोई उचित alternative आने तक, चाहे बगल में Kitty चलाऊँ, काम के लिए tmux ही इस्तेमाल करता रहूँगा
लेकिन अंत में मैं फिर tmux और default terminal के combination पर लौट आया
यह हर जगह अच्छी तरह काम करता है, और tools को जोड़कर इस्तेमाल करने का तरीका ज़्यादा टिकाऊ है; इसी वजह से tmux अब भी सबसे अच्छा विकल्प है