आपके PATH में टिल्ड शायद आपका HOME नहीं है

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

Shell commands में `~` का उपयोग—खासकर `PATH` बदलते समय—बहुत अलग तरह से व्यवहार कर सकता है जितना कई उपयोगकर्ता उम्मीद करते हैं, क्योंकि tilde expansion केवल कुछ खास unquoted positions में होता है और POSIX shells तथा Bash/Zsh extensions के बीच बदलता रहता है। Commenters literal `~` को `PATH` में डाल देने या यहाँ तक कि `$HOME` मिटा देने जैसी गलतियों के उदाहरण देते हैं, user-local directories को system paths से पहले रखने या बाद में जोड़ने पर बहस करते हैं, और Bash के कई “footguns” की तुलना fish, nushell, और zsh जैसे वैकल्पिक shells से करते हैं। यह चर्चा दिखाती है कि subtle quoting और expansion rules, साथ ही असंगत tooling और documentation, robust shell usage और scripting को जितना दिखता है उससे कहीं कठिन बना देते हैं.

टिल्ड विस्तार और PATH का व्यवहार

  • टिल्ड केवल कुछ विशिष्ट स्थितियों में expand होता है: अनquoted “word” की शुरुआत में; और कुछ shells में assignments में अनquoted colons के बाद भी।
  • ~ को quote करने से expansion रुक जाता है और PATH में literal ~ रह सकता है, जो मूल समस्या है।
  • कुछ shells (zsh, fish) ~/.local/bin को PATH में जोड़ने के लिए अधिक सुविधाजनक या array-आधारित तरीके देते हैं, जो expansion को सही तरह संभालते हैं।
  • कई commenters scripts में ~ की बजाय $HOME इस्तेमाल करना पसंद करते हैं ताकि surprises से बचा जा सके।

Quoting के नियम और आम shell footguns

  • कब quote करना है, इसे गलत समझना bugs का बड़ा कारण है: लोग या तो बहुत ज़्यादा quote करते हैं या बहुत कम।
  • दी गई सलाह:
    • argument में variable expansions ("$var") हमेशा quote करें ताकि word-splitting और globbing से बचा जा सके।
    • single quotes का उपयोग केवल literal strings के लिए करें जिनमें special characters हों।
  • variable expansion और tilde expansion अलग तरह से काम करते हैं; इन्हें एक जैसा मानना गलतियों की ओर ले जाता है।

PATH का क्रम और सुरक्षा

  • इस पर बहस कि ~/.local/bin जैसे user directories को prepend करना चाहिए या append।
    • एक पक्ष: append करें ताकि system binaries को precedence मिले, और malicious overrides का जोखिम कम हो।
    • दूसरा पक्ष: prepend करें ताकि users पुराने system tools को जानबूझकर override कर सकें।
  • आम सहमति यह है कि अगर कोई attacker आपके PATH directories में लिख सकता है, तो आपके पास पहले से ही गंभीर compromise है।

POSIX बनाम shell-specific व्यवहार

  • लेख के कुछ व्यवहार bash/zsh extensions पर निर्भर हैं और /bin/sh (अक्सर dash या ash) में portable नहीं हैं।
  • POSIX tilde expansion के नियमों का हवाला दिया गया; पहले कुछ भ्रम था, फिर स्पष्ट किया गया कि assignments में अनquoted : के बाद expansion अनुमति है।
  • कई reminders दिए गए कि “bashisms” और strictly POSIX-compliant constructs में अंतर करें।

वैकल्पिक shells और भाषा विकल्प

  • कई लोगों ने bash को “terrible” या fragile scripting language कहा, जिसमें बहुत सारे edge cases हैं।
  • उल्लेखित विकल्प: fish, zsh, nushell, murex, PowerShell, Perl, Ruby, आदि।
  • प्रतिवाद: bash/sh अब भी dominant हैं क्योंकि वे हर जगह preinstalled होते हैं, खासकर remote systems पर।

Filenames, characters, और robustness

  • कुछ लोगों का तर्क है कि अगर paths में केवल restricted ASCII set allowed होता, तो encoding और parsing issues कम होते।
  • दूसरे लोग non-Latin scripts और arbitrary Unicode के समर्थन का ज़ोरदार बचाव करते हैं, tooling की परेशानियों के बावजूद।
  • filenames में spaces या leading - को bugs और security pitfalls का frequent source बताया गया।

Environment, HOME, और debugging

  • $HOME और system databases में account के home के बीच अंतर पर ध्यान दिलाया गया; ये अलग हो सकते हैं और ~ resolution को confuse कर सकते हैं।
  • testing के लिए HOME को बदलना उन tools से टकरा सकता है जो home directories को अलग तरीके से resolve करते हैं।
  • बड़े संगठनों में shell startup files की कई परतें होती हैं, जिससे यह ट्रैक करना कठिन हो जाता है कि variables कहाँ set हो रहे हैं; shell startup के लिए tracing tools सुझाए गए।

War stories और सीख

  • कई anecdote: literal ~ directory बन जाना, गलती से rm -r ~ चला देना, और AI tools का ~ directories बना देना।
  • निकाले गए lessons: जहाँ संभव हो rm -r से बचें, अधिक स्पष्ट paths (./~) इस्तेमाल करें, और shell features के साथ सावधानी बरतें.