मॉडर्न Linux टूल्स का संग्रह: पारंपरिक कमांड्स को बदलने वाले नए CLI

• Linux पर काम की दक्षता बढ़ाने वाले कई आधुनिक command-line टूल्स का परिचय
• पारंपरिक Unix कमांड्स को आधुनिक तरीके से बदलने या उनकी क्षमताएँ बढ़ाने वाले, और Rust·Go आदि में बने performance-केंद्रित टूल्स की बड़ी सूची शामिल

फ़ाइल देखने और नेविगेट करने के टूल्स

• bat : cat कमांड का syntax highlighting और git integration के साथ बेहतर संस्करण
• exa : ls/tree का विकल्प देने वाला आधुनिक file list viewer, लेकिन फिलहाल maintenance बंद है
• eza : exa का fork, जो आधुनिक ls/tree प्रदान करता है
• lsd : next-generation ls, जो पुरानी compatibility और अधिक सलीकेदार output देता है
• broot : बेहतर navigation वाला tree-आधारित file explorer
• nnn : हल्का और तेज़ terminal file manager

फ़ाइल·डायरेक्टरी क्षमता विश्लेषण

• ncdu : text-आधारित सहज du interface प्रदान करता है
• dust : Rust में बना ज़्यादा आसान du replacement
• duf : पारंपरिक df से बेहतर usability वाला disk usage analysis टूल

फ़ाइल और कोड खोज

• fd : सरल और तेज़ find replacement जिसकी usability शानदार है
• ripgrep : gitignore सपोर्ट वाला बेहद तेज़ grep replacement
• ag : ack जैसा लेकिन उससे भी तेज़ code search टूल
• fzf : general-purpose fuzzy finder. pipeline समेत कई जगह उपयोगी
• bfs : breadth-first आधारित find replacement

टर्मिनल के भीतर Git/diff viewer

• delta : git और diff के नतीजों को ज़्यादा पठनीय तरीके से visualize करता है

कमांड हिस्ट्री और प्रोसेसिंग

• mcfly : shell history search·navigation को काफी बेहतर बनाता है. बेहतर search quality और सहज UI देता है

डेटा प्रोसेसिंग

• choose : cut और कुछ awk उपयोगों का ज़्यादा सहज और तेज़ विकल्प
• jq : JSON-विशेष sed की तरह उपयोग होने वाला data parser
• sd : ज़्यादा परिचित find/replace अनुभव देने वाला sed replacement

सिस्टम/प्रोसेस मॉनिटरिंग

• bottom : cross-platform ग्राफ़िक-आधारित system·process monitor
• glances : top/htop का बेहतर संस्करण
• gtop : terminal dashboard-शैली system monitor
• procs : Rust में लिखा ps replacement command

बेंचमार्किंग·नेटवर्क

• hyperfine : CLI benchmarking automation टूल
• gping : graph output feature के साथ आने वाला ping टूल

HTTP क्लाइंट

• httpie : आधुनिक और उपयोगकर्ता-अनुकूल CLI HTTP client. developer API testing के लिए उपयुक्त
• curlie : curl की ताकत को httpie की usability के साथ जोड़ने वाला टूल
• xh : performance-केंद्रित httpie replacement

डायरेक्टरी मूवमेंट·एडिटर

• zoxide : z से प्रेरित smart cd command
• micro : आधुनिक सुविधाओं वाला terminal text editor

नए उभरते CLI utilities

• up : real-time preview pipeline टूल, कमांड output तुरंत देखा जा सकता है

हेल्प·डॉक्यूमेंटेशन टूल्स

• ManKier : संक्षिप्त man pages, साफ़-सुथरे command descriptions
• tldr : संक्षिप्त, example-केंद्रित man page summaries
• tealdeer : Rust-आधारित tldr implementation, तेज़ execution speed
• explainshell : command arguments का auto-analysis कर अर्थ को visual तरीके से समझाता है
• cheat.sh : tldr और cheatsheet को मिलाने वाली online help service

GUI टूल्स

• baobab : GUI-आधारित disk usage analyzer
• stacer : system optimization और monitoring GUI टूल, service management सहित

[GN⁺]

Hacker News की राय

• हो सकता है कि ये टूल वस्तुनिष्ठ रूप से बेहतर हों, लेकिन हर बार नया OS इंस्टॉल करने, VM चलाने या SSH से कनेक्ट होने पर इन्हें सेटअप करना कभी न खत्म होने वाली मशक्कत है—यह बात मैंने सीखी है। हर environment में अलग से सेटिंग करना थका देने वाला है, और मैं यह भी नहीं चाहता कि कहीं नए टूल और कहीं पारंपरिक टूल मिलाकर इस्तेमाल करूँ। क्लासिक टूल्स को ठीक से सीख लेना ही आखिरकार जीवन सबसे आसान बनाता है

  • कुछ लोग अपना ज़्यादातर समय अपनी ही मशीन पर बिताते हैं, इसलिए ऐसी convenience improvements उनके लिए बहुत मूल्यवान होती हैं। फिर भी उन्हें क्लासिक टूल्स का भी काफ़ी इस्तेमाल करना आता है, इसलिए कभी-कभार दूसरे सर्वरों पर काम करते समय भी काम चल जाता है। हर कोई ऐसा sysadmin नहीं होता जिसे दिन भर कई तरह के सर्वरों में लॉग इन करना पड़े

  • कुछ टूल इतने ज़्यादा बेहतर होते हैं कि थोड़ा झंझट वाला installation भी पूरी तरह सार्थक लगता है। मुझे क्लासिक टूल्स अच्छी तरह आते हैं, लेकिन fd या ripgrep हमेशा बेहतर लगते हैं

  • मुझे Nix बहुत पसंद आने की असली वजह यह है कि लगभग हर environment में एक जैसा setup मिल सकता है (जब तक मेरा environment linux या macOS हो; मैं बस इन्हीं दो की परवाह करता हूँ)। Nix को root permission के बिना इंस्टॉल करने के भी कई तरीके हैं, इसलिए मैं लगभग कहीं भी अपना environment जैसा का तैसा बना लेता हूँ। बेशक Nix न हो तो भी क्लासिक टूल्स से काम हो जाता है। ऐसा नहीं है कि आपको इनमें से सिर्फ़ एक ही चुनना है; दोनों रखे जा सकते हैं

  • नया OS इंस्टॉल करते समय वैसे भी ज़रूरी packages को apt-get, pacman, dnf, brew जैसी चीज़ों से इंस्टॉल करना पड़ता है, और अपना browser या editor वगैरह भी अलग से लगाना ही होता है। SSH से लॉग इन करने पर GUI तो चल ही नहीं सकता, लेकिन इससे GUI टूल्स से बचने की कोई वजह नहीं बनती। अगर personal environment और shared environment में टूल्स का सेट अलग हो, तो भी मुझे यह कोई बड़ा मुद्दा नहीं लगता। उदाहरण के लिए bat, cat को पूरी तरह replace नहीं करता; वह बस syntax highlighting जोड़कर जीवन आसान बना देता है। अगर इंस्टॉल न हो, तो बस इस्तेमाल मत करो

  • मेरी राय में “एक काम बहुत अच्छे से करो” वाली UNIX philosophy के हिसाब से, जब कोई बेहतर विकल्प आता है तो उसे आसानी से replace कर पाना ही इन simple utilities की असली खासियत है। करियर के लिए क्लासिक टूल्स पहले सीखना सही है, लेकिन नए विकल्प भी ज़रूर सीखने चाहिए। मेरे लिए bat या eza से ज़्यादा fd (find का विकल्प), sd (sed का विकल्प) जैसे time-saving विकल्प सच में मददगार हैं

• कई networks, ग्राहकों और सैकड़ों servers पर काम करने की स्थिति में custom टूल्स का मूल्य लगभग नहीं के बराबर है। वजह यह है कि 90% environments में ये टूल्स इंस्टॉल ही नहीं होते। मैं automation के ज़रिए ansible-config में बस कुछ चीज़ें जोड़कर deploy करता हूँ, लेकिन सूची को बहुत संक्षिप्त रखता हूँ। जिन systems को मैं manage करता हूँ उनमें 95% debian या ubuntu हैं, इसलिए baseline लगभग एक जैसा है, और उसके ऊपर सिर्फ़ ack, etckeeper, vim, pv, dstat जैसी चीज़ें जोड़ता हूँ

  • यहाँ "server" वाला पहलू अहम है। ज़्यादातर हल्के-फुल्के सुधरे हुए sysadmin प्रोग्राम शायद उतने मूल्यवान न हों, लेकिन कुछ सचमुच dev tools हैं जो development environment में काम आते हैं और उन्हें बस उन कुछ machines पर इंस्टॉल करना होता है जिन पर programming की जाती है। ripgrep (बेहतरीन recursive grep), jq (JSON processor, जिसका unix की default toolkit में कोई विकल्प नहीं), hyperfine (benchmarking) इसके अच्छे उदाहरण हैं

  • Windows और Linux के बीच आते-जाते काम करने पर ripgrep जैसे बेहतरीन cross-platform टूल सच में बहुत सुविधाजनक लगते हैं

  • मुझे जिज्ञासा है कि क्या कोई ऐसा टूल या SSH extension है जो इन apps को remote SSH session में अपने-आप ले आए। अगर binary छोटी हो, तो उसे temp folder में कॉपी करके चलाया जा सकता है, और उस प्रक्रिया को automate करना भी कल्पना से बाहर नहीं है। बस सवाल यह है कि क्या इसमें security concerns होंगे, या क्या extra permissions चाहिए होंगी। आखिरकार इन apps की portability ही असली मुद्दा है। मैं भी इस बारे में अक्सर सोचता हूँ

  • emacs लगभग एक operating system की तरह काम करता है, इसलिए किसी भी system पर एक परिचित environment मिल जाता है। इसी वजह से “GNU is my operating system, linux is just the current kernel” जैसी बात कही जाती है। एक अनुभवी admin के नज़रिए से, जो लोग Linux सीखना शुरू कर रहे हों उन्हें मैं पहले info command देखने और उसकी manuals पढ़ने की सलाह देता हूँ। इससे आप ज़्यादातर admins से बहुत आगे निकल सकते हैं। अगर आपको built-in tools का पता हो, तो manuals भी अच्छी लगती हैं और scripting आसान हो जाती है—यही Linux philosophy का मूल है। एक समय ऐसा भी था जब nano नहीं होता था और सिर्फ़ vi होता था, लेकिन आजकल CI/CD automation से tui editor जोड़ना भी आसान है

  • इस तरह की “मैं कौन हूँ” वाली टिप्पणियों से मुझे ज़्यादा जुड़ाव नहीं लगता। बहुत से लोगों को इस बात से कोई फ़र्क नहीं पड़ता कि वे custom tools को remote पर इंस्टॉल नहीं करेंगे। बात बस इतनी है कि कम-से-कम अपने local computer पर तो ऐसे tools लगाकर उनका लाभ लिया जाए

• मुझे लगता है कि इस तालिका में “यह टूल किस समस्या को हल करता है” वाला एक अतिरिक्त column होना चाहिए। और “Rust में लिखा गया है” जैसी बात मुझे कोई differentiator नहीं लगती

  • मुझे एक बार company meeting में यह सुनकर बहुत अजीब लगा था कि “Go में लिखा है” कोई खास differentiator है। #facepalm

  • तालिका की कई entries वास्तव में समस्या बताती हैं, जैसे “syntax highlight”, “ncurses interface”, “more intuitive”। लेकिन “Rust में लिखा”, “modern”, “better” जैसे शब्द मुझे मददगार नहीं लगते

  • ज़्यादातर tools का प्राथमिक उद्देश्य UX सुधारना है

  • non-GPL license भी कोई differentiator नहीं है

  • इनमें से काफ़ी tools Windows पर भी उपलब्ध हैं, यह अच्छी बात है

• ऐसे tool lists हमेशा मज़ेदार लगते हैं। ज़्यादातर लोग शायद यहाँ से एक-दो tools तो ज़रूर अच्छे से इस्तेमाल कर सकेंगे। मेरे लिए व्यक्तिगत तौर पर ripgrep और jq अनिवार्य हैं। ripgrep, grep के विकल्पों में सबसे अच्छा drop-in है, और jq ने ठीक वही समस्या हल की जिसे मुझे सच में हल करना था। मैं lsd और dust भी आज़माना चाहूँगा। भले कोई नया टूल मुझे सीधे ज़रूरी न लगे, फिर भी मुझे अच्छा लगता है कि लोग इन tools पर समय लगाते हैं। पूरे समुदाय के toolbox को थोड़ा-थोड़ा बेहतर बनाना अपने-आप में शानदार बात है

  • मैं सबसे पहले fzf चुनूँगा। मुझे यह rg या jq से भी ज़्यादा पसंद है

  • ripgrep का व्यवहार grep से अलग है, इसलिए वह वास्तव में drop-in replacement नहीं है। यह शानदार program है, लेकिन पूरी तरह compatible नहीं है

  • मेरी तरह Linux admins के पास आमतौर पर ऐसी कसकर चुनी हुई सूची होती है। मैंने अपना stack ज़्यादातर GPL-आधारित tools के आसपास बनाया है, और यह ikrima.dev format मुझे ख़ास तौर पर पसंद है

• मैं terminal में ही जीता हूँ, लेकिन ये tools या तो मेरी तत्काल समस्या हल नहीं करते, या मेरे system में इंस्टॉल नहीं होते, फिर भी किसी तरह इन पर GitHub के दसियों हज़ार stars हैं। आखिर इनकी इतनी लोकप्रियता किस वजह से है, यह मुझे समझ नहीं आता

  • जो लोग अपनी music library में जीते हैं, वे भी कभी-कभी यह देखकर हैरान हो सकते हैं कि कोई ऐसा artist जिसे वे पसंद नहीं करते, या जो उनकी library में है ही नहीं, लाखों records बेच देता है। मज़ाक अपनी जगह, लेकिन मैं पूछना चाहूँगा कि क्या आपने खुद इनमें से किसी tool को सच में इस्तेमाल किया है। मुझे भी पहले समझ नहीं आता था कि लोग vim क्यों इस्तेमाल करते हैं, लेकिन जब मैंने उसे ठीक से इस्तेमाल किया, तब वजह समझ आई

  • fzf इस्तेमाल नहीं करते? तब तो terminal life काफ़ी कठिन लगती होगी। सीधे run करने से भी ज़्यादा उपयोगी यह है कि shell plugins के ज़रिए Ctrl+R से bash_history और Ctrl+T से current directory की files का fuzzy search मिल जाता है

  • core unix toolset इतना मज़बूत है कि default tools से भी आराम से काम हो जाता है। कई alternative tools बेहतर हैं, लेकिन वे अनिवार्य नहीं हैं, और ऊपर से ज़्यादातर default install में होते भी नहीं

  • जिज्ञासा से पूछ रहा हूँ: क्या built-in unix tools से hidden files (.git आदि) को ignore करते हुए और सिर्फ़ किसी खास extension पर recursive grep करने का कोई elegant तरीका है? उदाहरण के लिए rg -g '*.foo' bar ऐसा pattern है जो मैं बहुत इस्तेमाल करता हूँ। इसी तरह fd से regex या glob से match करने वाली files ढूँढना भी। default tools के साथ मुझे इसका कोई साफ़-सुथरा तरीका नहीं मिला

  • मुझे यह जानने की उत्सुकता है कि terminal में दिन भर किस तरह का काम किया जाता है कि toolset को बेहतर बनाने की इच्छा ही न हो। मन में आता है पूछूँ—क्या आप अपने सारे tools खुद लिखते हैं?

• dark mode में link text बहुत कम दिखाई देता है, इसलिए पढ़ना मुश्किल है

• मुझे लगता है कि सिर्फ़ jq ही ऐसा है जो ऐसी वास्तविक समस्या हल करता है जिसे मौजूदा tools से ठीक तरह हल नहीं किया जा सकता। बाकी ज़्यादातर चीज़ें बस preference, performance, highlighting या Rust implementation जैसी भिन्नताएँ हैं

• मेरी इच्छा है कि कोई team parameters, colors, tables वगैरह के design को एक जैसा रखकर tools की एक पूरी “suite” बनाए

• मैं लंबे समय तक htop को top से ज़्यादा accessible मानकर इस्तेमाल करता रहा, लेकिन htop default रूप से kernel threads नहीं दिखाता, और इसने incident diagnosis में रुकावट डाली। उसके बाद मैं फिर top पर लौट आया क्योंकि वह सारी जानकारी दिखाता है और ज़्यादा भरोसेमंद है। htop/btop जैसी UI मुझे अब लगभग showmanship जैसी लगती हैं

• यह लेख 2023 का है। संभव है कि ज़्यादातर “modern tools” अब तक अपडेट हो चुके हों और नए trendy विकल्प भी आ गए हों

  • tools इतने ज़्यादा हैं कि अगर आधे भी टिके रहें, तब भी यह काफ़ी मूल्यवान है

  • मेरा अनुभव तो उल्टा रहा है। इनमें से ज़्यादातर tools बस बेहद शक्तिशाली GNU default tools का एक और “reinvention” लगते हैं—अगर आप समय लगाकर उन्हें सही से सीख लें तो वही काम हो जाता है