एक shell colon कुछ नहीं करता। फिर भी इसका उपयोग करें

मूल लेख ↗ Hacker News चर्चा ↗

POSIX shell के no-op `:` command पर एक blog post इस बहस को जन्म देती है कि क्या ऐसे terse idioms चतुर power tools हैं या readability के लिए खतरा। टिप्पणियाँ argument validation, redirection, और scripting tricks में `:` के practical उपयोगों को उजागर करती हैं, लेकिन कई लोग तर्क देते हैं कि multi-line logic को opaque one-liners में समेटना shell scripts को बनाए रखना कठिन बना देता है, खासकर बड़े पैमाने पर। यह चर्चा shell scripting की खुद की आलोचना तक फैलती है—उसके footguns, portability quirks, और Python, PowerShell, तथा LLM-generated code के युग में उसकी भूमिका।

: (null) कमांड की उपयोगिता

  • कई लोगों को कुछ idioms वास्तव में उपयोगी लगते हैं, खासकर:
    • आवश्यक arguments/env vars को सत्यापित करना: ${1:?missing argument} या VAR="${VAR:?message}".
    • डिफ़ॉल्ट देना: : "${DOTFILES_PATH:=$HOME/.dotfiles}".
    • जब किसी command की syntactically आवश्यकता हो, तब if/while में placeholder के रूप में काम करना।
    • functions के अंदर “docstring” लाइन के रूप में या खोज में मदद के लिए dummy alias के रूप में सेवा करना।
  • दूसरों को इनमें से अधिकांश उदाहरण चतुर तो लगते हैं, लेकिन अव्यावहारिक; ये मुख्यतः readable code को one-liners में समेट देते हैं।

Redirection, truncation, और portability के विवरण

  • कुछ लोग बताते हैं कि : >file file को truncate भी करता है और create भी, जिसे लेख में कथित तौर पर कम महत्व दिया गया है।
  • चर्चा स्पष्ट करती है कि redirections : के बिना भी काम कर सकते हैं, लेकिन shells के बीच व्यवहार अलग होता है (जैसे, zsh < file के लिए file contents प्रिंट करेगा जब तक उसे : से जोड़ा न जाए)।
  • Subshell बनाम non-subshell उदाहरण set -e / --posix के तहत अलग व्यवहार दिखाते हैं, इसलिए कुछ परिस्थितियों में ( : < file ) उचित ठहरता है।
  • : एक builtin है, जबकि true बाहरी utility हो सकती है; : arguments को सुरक्षित रूप से ignore करता है, इसलिए कभी-कभी इसे प्राथमिकता दी जाती है।

Readability बनाम cleverness

  • समझने योग्य multi-line code को dense one-liners में बदलने के खिलाफ़ कड़ा विरोध।
  • कई लोगों का तर्क है कि छोटे scripts से आगे, चीज़ों को स्पष्टता और explicit error-handling को प्राथमिकता देनी चाहिए, terseness को नहीं।
  • कुछ इसे मज़ेदार puzzles मानते हैं, personal use या golfed code के लिए उपयुक्त, लेकिन production में अस्वीकार्य।

Shell बनाम अन्य भाषाएँ (और LLMs)

  • कई टिप्पणियाँ तर्क देती हैं कि बड़े programs के लिए POSIX shell syntax मूल रूप से खराब है; maintainable scripts के लिए Python/Ruby/PowerShell बेहतर हैं।
  • अन्य लोग shell का बचाव करते हैं कि यह छोटे automation और process orchestration के लिए uniquely suited है, अपनी quirks के बावजूद, खासकर जब ShellCheck जैसे tools का सहारा हो।
  • बताया गया है कि LLMs जटिल shell/Perl scripts बनाने में अच्छे हैं, लेकिन फिर भी review की ज़रूरत होती है; quality और over-engineering बार-बार उठने वाली शिकायतें हैं।

Alternative shells और ecosystems

  • fish, nushell, oil, zsh, और विशेष रूप से PowerShell के अधिक modern या expressive विकल्प होने के उल्लेख, जिन पर बहस होती है:
    • Startup time और dependency footprint।
    • “system shell” बनाम scripting language के रूप में उपयुक्तता।
    • Verbosity, complexity, और cross-platform उपलब्धता।