Windows के लिए Coreutils

“Windows के लिए Coreutils” का अवलोकन

  • Rust/uutils के एक फोर्क के माध्यम से (अधिकांश) GNU coreutils का नेटिव Windows पोर्ट।
  • लक्ष्य: Linux, macOS, WSL, कंटेनरों और Windows के बीच जाना अधिक “frictionless” बनाना ताकि कई मौजूदा स्क्रिप्ट्स न्यूनतम बदलावों के साथ काम करें।
  • प्रोजेक्ट के लगभग 75% utilities शिप करने की रिपोर्ट है; कुछ जानबूझकर छोड़े गए हैं या बदले गए हैं।

uutils, GNU coreutils, और लाइसेंसिंग से संबंध

  • यह मौजूदा Rust uutils coreutils का एक फोर्क है, GNU coreutils का सीधे पोर्ट नहीं।
  • कुछ लोग इसे अनावश्यक मानते हैं क्योंकि uutils पहले से Windows सपोर्ट करता है और अंतर मुख्यतः Windows-विशिष्ट fixes हैं जिन्हें “upstreamed” किया जा सकता था।
  • MIT-licensed uutils और यह फोर्क GPL को बायपास करने में मदद करते हैं—इस पर कड़ी आलोचना; कुछ इसे GNU/GPL पर हमले और “EEE”-शैली के व्यवहार के रूप में देखते हैं।
  • दूसरों का तर्क है कि MIT licensing अपना काम कर रही है, यानी adoption को अधिकतम कर रही है।

Shell conflicts और व्यवहार

  • कई commands CMD/PowerShell built-ins (dir, echo, sort, find, आदि) से टकराती हैं।
  • व्यवहार shell, PATH ordering, और PowerShell aliases पर निर्भर करता है; उपयोगकर्ताओं का कहना है कि इससे “drop-in” लक्ष्य कमजोर पड़ता है।
  • find/sort के लिए DOS और GNU variants के बीच heuristics के आधार पर dispatch करने जैसे hacks हैं; कुछ लोगों को यह messy और कम समझाया हुआ लगता है।
  • सुझावों में commands को prefix करना (जैसे BSD/macOS पर g*) या ऐसा dedicated environment होना शामिल है जहाँ ये tools PATH में पहले आएँ।

छूटी हुई / कम प्राथमिकता दी गई utilities

  • कुछ commands (जैसे shred, uname) को “Windows पर उपयोगी नहीं” मानकर छोड़ दिया गया या कम महत्व दिया गया, जिसे कई लोग असहमतिपूर्ण मानते हैं।
  • अन्य लोग कहते हैं कि स्पष्ट रूप से उपयोगी tools (dd, एक सही chown/chmod, बेहतर ln integrations, uname) को प्राथमिकता मिलनी चाहिए थी।
  • README में केवल conflicted या excluded commands सूचीबद्ध होने से भ्रम हुआ; स्पष्ट किया गया कि “जो कुछ सूचीबद्ध नहीं है, वह शामिल है।”

मौजूदा विकल्पों से तुलना

  • बहुत से लोग पूछते हैं कि बस ये क्यों न इस्तेमाल करें:
    • Cygwin/MSYS2, Git for Windows (Bash के साथ), Busybox for Windows, WSL/WSL1, या मौजूदा uutils।
  • आलोचकों को यह आधा-पका, marketing-driven duplication लगता है जो Windows पर एक और सूक्ष्म रूप से असंगत Unix-like environment जोड़ देता है।

प्रेरणाएँ और AI कोण

  • कुछ लोग अनुमान लगाते हैं कि असली चालक AI agents हैं: LLMs PowerShell/CMD की तुलना में Unix-style CLI में बेहतर हैं, इसलिए native coreutils “Windows पर agents” के लिए मददगार हैं।
  • प्रोजेक्ट प्रतिनिधियों का कहना है कि प्राथमिक लक्ष्य macOS/Linux से परिचित human developers हैं; AI लाभ एक side effect हैं।

Windows UX पर व्यापक बहसें

  • थ्रेड बार-बार होने वाले विषयों में चला जाता है: CRLF बनाम LF, backslashes बनाम slashes, drive letters, POSIX compatibility, UTF-16, और PowerShell का object pipeline बनाम Unix tools का text-based मॉडल।
  • कोई सहमति नहीं: कुछ लोग इन tools का स्वागत quality-of-life सुधार के रूप में करते हैं; अन्य कहते हैं कि वे फिर भी Linux, WSL, या मौजूदा Unix layers का ही उपयोग करना पसंद करेंगे।