2024-02-06

कमांड लाइन इंटरफ़ेस दिशानिर्देश (2021)

कमांड-लाइन इंटरफ़ेस डिज़ाइन को “स्वर्ण युग” में बताया गया है, लेकिन साथ ही दशकों की असंगत परंपराओं से सीमित भी माना गया है—POSIX flags और `getopt` से लेकर `git` और `kubectl` जैसी idiosyncratic mega-CLIs तक। योगदानकर्ता CLIs, TUIs और GUIs के बीच trade-offs पर विचार करते हैं, और discoverability, destructive commands के लिए safe defaults, `--dry-run` modes, output formatting (JSON, color, emoji), help behavior, तथा stdout बनाम stderr के सही उपयोग जैसी usability समस्याओं पर बहस करते हैं। स्पष्ट, अधिक सुसंगत दिशानिर्देशों और बेहतर tooling (PowerShell-शैली सुविधाओं और secrets handling सहित) के लिए व्यापक समर्थन है, साथ ही इस बात पर संदेह भी कि legacy Unix toolchain और मौजूदा scripts को आधुनिक UX आदर्शों के अनुरूप आसानी से बदला जा सकता है।

CLI बनाम TUI बनाम GUI

कुछ लोगों का तर्क है कि TUIs “सामान्य उपयोगकर्ता” के लिए आदर्श हैं: एकसमान फ़ॉन्ट आकार, घनी लेकिन संरचित लेआउट, कीबोर्ड-प्रभावशीलता, और SSH-फ्रेंडली होना।
अन्य लोग जवाब देते हैं कि TUIs में GUI जैसी कई कमियाँ होती हैं, वे अधिक खोजयोग्य नहीं होते, और अच्छी तरह डिज़ाइन किए गए GUIs टर्मिनल सीमाओं के बिना TUI संरचना की नकल कर सकते हैं।
कई लोग नोट करते हैं कि CLIs पूर्ण उपयोगकर्ता संख्या के हिसाब से “स्वर्ण युग” में हैं, लेकिन यह बहस जारी है कि क्या वे सभी कंप्यूटर उपयोगकर्ताओं के सापेक्ष अधिक महत्वपूर्ण हैं।

शेल, संयोजन, और POSIX टूल

इस पर बहस कि Unix कमांड मुख्यतः प्रोग्रामेटिक उपयोग के लिए थे या इंटरैक्टिव शेल उपयोग के लिए; सहमति है कि शेल प्रोग्रामिंग भाषाएँ हैं, लेकिन बड़े प्रोग्रामों के लिए आदर्श नहीं हैं।
“shell as glue” के लिए मजबूत समर्थन: C या अन्य बाइनरीज़ को ऑर्केस्ट्रेट करने वाली छोटी शेल स्क्रिप्ट्स कहीं बड़े प्रोग्रामों की जगह ले सकती हैं।
POSIX getopt का व्यापक संदर्भ दिया गया है, लेकिन स्पष्ट किया गया कि यह एक POSIX सुविधा है, भाषा-विशेषता नहीं।

कमांड-लाइन डिज़ाइन परंपराएँ और समस्याएँ

नेस्टेड सबकमांड पदानुक्रमों पर मिश्रित विचार: ये स्थानीय जटिलता कम कर सकते हैं लेकिन खोजयोग्यता को कठिन बनाते हैं, बनिस्बत एक बड़े help पेज के।
फ़्लैग capitalization की असंगति और संयुक्त short flags पर शिकायतें; कुछ लोग चाहते हैं कि नए टूल लंबे, स्पष्ट फ़्लैग्स को प्राथमिकता दें और पेचीदा short-option semantics से बचें।
मनमाने subcommand abbreviations से बचने की अपील, खासकर scripts में, ताकि भविष्य की extensibility बनी रहे।
कुछ लोग मानते हैं कि दिशानिर्देश दस्तावेज़ लंबा है, जबकि अन्य इसे सामान्य UI गाइड्स की तुलना में संक्षिप्त मानते हैं।

मशीन-पठनीय आउटपुट और फ़ॉर्मैट

human- और machine-readable CLIs के बीच तनाव को “design by broken” कहा गया; --json modes और/या IO-format environment variables के सुझाव दिए गए हैं।
चिंता है कि environment variables वैश्विक नियंत्रण को सरल भी बना सकते हैं और subtle bugs या bloating भी ला सकते हैं।
PowerShell को structured output के साथ आंशिक समाधान के रूप में उठाया गया, लेकिन उसे verbose और कभी-कभी उपयोग में कठिन भी कहा गया।

सुरक्षा, dry run, और destructive commands

--dry-run / “what-if” व्यवहार के लिए मजबूत समर्थन, कभी-कभी डिफ़ॉल्ट के रूप में भी, जिसमें स्पष्ट --execute/--commit की आवश्यकता हो।
सुझाए गए पैटर्न:
- ऐसे टूल जो केवल shell commands emit करें, ताकि उपयोगकर्ता उन्हें inspect/edit करके sh में pipe कर सकें।
- overlay filesystems के माध्यम से try-style sandboxing।
कुछ लोग सुरक्षा prompts जोड़ने के लिए core utilities को पुनःimplement करते हैं; अन्य लोग -i के साथ shell aliases को पसंद करते हैं।

Secrets का प्रबंधन

environment variables में secrets न रखने वाली guideline पर बहस होती है।
विकल्पों में strict permissions वाली credential files, systemd credentials, और “secret fetch करने के लिए यह command चलाएँ” hooks शामिल हैं, जो password managers या services को delegate कर सकते हैं।
managed environments में secrets managers सुविधाजनक माने जाते हैं; व्यक्तिगत projects के लिए यह कम स्पष्ट है।

Help, दस्तावेज़ीकरण, और खोजयोग्यता

उन tools से निराशा जो help के लिए -? या समान विकल्प स्वीकार नहीं करते, बजाय इसके कि केवल usage print करें।
कुछ लोगों को निराशा है कि दिशानिर्देश केवल man pages पर “consider” कहते हैं; अन्य लोग नोट करते हैं कि बड़े CLIs के लिए man pages और समृद्ध --help अभी भी महत्वपूर्ण हैं।

Stdout/stderr और output UX

मजबूत तर्क कि सारी logging, progress, animations, और status messages stderr पर होने चाहिए; pipelines को विश्वसनीय बनाए रखने के लिए stdout को “primary result” के लिए सुरक्षित रखा जाना चाहिए।
विशेष रूप से non-TTY stdout पर animations की आलोचना की जाती है क्योंकि वे logs को तोड़ती हैं; कुछ लोग कहते हैं कि animations कभी भी stdout पर नहीं होनी चाहिए।
emojis और सजावटी symbols विभाजनकारी हैं: कुछ लोगों को वे उपयोगी और visually scannable लगते हैं; अन्य लोग असंगति, terminal rendering समस्याओं, और दिखावटीपन को नापसंद करते हैं, और सुझाव देते हैं कि वे वैकल्पिक हों तथा text के साथ redundant हों।

Versioning, deprecation, और CLI जटिलता

CLI deprecation को विशेष रूप से कठिन माना जाता है क्योंकि commands तुरंत script की जाती हैं और libraries में सामान्य version pinning semantics की कमी होती है।
private paths में binaries copy करने जैसे workaround पर चर्चा होती है, लेकिन dependencies के कारण उन्हें fragile माना जाता है।
“mega-CLIs” (जैसे multi-subcommand tools) का बढ़ना classic “do one thing well” Unix ethos से हटना माना जाता है, लेकिन आधुनिक जटिलता के व्यावहारिक जवाब के रूप में इसे स्वीकार भी किया जाता है।