क्या कारण थे कि विंडोज में कभी भी एक अच्छा शेल क्यों नहीं था? [बन्द है]

Question

मैं SO पर एक विषय पढ़ रहा था: स्क्रिप्टिंग भाषाएं क्यों हैं (उदा ...) शेल भाषाओं के रूप में उपयुक्त नहीं हैं? । विशेष रूप से मुझे जोर्ग डब्ल्यू मित्तग का जवाब पसंद आया , जिससे मैंने इसके बारे में दिलचस्प बातें सीखीं Windows PowerShell। इसलिए 20 से अधिक वर्षों के बाद विंडोज में आखिरकार एक अच्छी तरह से डिज़ाइन किया गया शेल (विंडोज 1.0 - 1985, पावरशेल स्थिर रिलीज - 2009) है। दूसरी ओर, यूनिक्स सिस्टम में 1978 बोर्न शेल के बाद से विभिन्न गोले का एक समूह है। मैंने एमएस जॉब इंटरव्यू के बारे में कुछ लेख पढ़े हैं और मुझे बहुत "geekish" कंपनी का आभास है। मैं सोच रहा हूं कि यूनिक्स लोगों की तुलना में उन्हें कमांड-लाइन टूल की आवश्यकता क्यों नहीं थी, जो उन उपकरणों के साथ अपने सभी काम करते हैं।

Comments

@ जेरेकॉफिन, यह संभवतः इस बात पर निर्भर करता है कि आप इस उद्योग में कितने समय तक थे। मैं अभी यहां शुरू कर रहा हूं इसलिए मैं इस सभी महान सॉफ्टवेयर से काफी खुश हूं जो मेरे लिए दिया गया था। बड़े सुधार के लिए जगह है लेकिन यह हमेशा रहेगा।

— स्की

कृपया चैट पर विस्तारित, ऑफ-टॉपिक चर्चा करें ।

Answer 1

यही कारण है कि iPod, iPhone (उस मामले के लिए कोई भी फोन), और iPad नहीं: कमांड लाइन विंडोज में कंप्यूटर के साथ उपयोगकर्ता इंटरैक्शन का प्राथमिक चैनल नहीं है। यह UNIX या GNU / Linux में है - इसलिए वे अधिक परिपक्व हैं। समान तर्क कि क्यों लिनक्स GUI डेस्कटॉप विंडोज की तुलना में इतने लंबे समय तक रगड़ रहे थे (मैक ओएस यहां धोखा देती है क्योंकि उन्हें यूनिक्स कमांड लाइन थोड़े मुफ्त में मिली थी)।

Answer 2

शायद मैं देख रहा हूँ, लेकिन मुझे लगता है कि यह एक सांस्कृतिक चीज़ है:

1. Microsoft संस्कृति में, डेवलपर्स अपने उपयोगकर्ताओं के लिए प्रोग्राम लिखने पर ध्यान केंद्रित करते हैं । कार्यक्रम सभी GUI- आधारित हैं।
2. यूनिक्स संस्कृति में, डेवलपर्स अन्य डेवलपर्स के लिए प्रोग्राम लिखने पर ध्यान केंद्रित करते हैं । कार्यक्रम छोटे होते हैं और किसी विशिष्ट चीज को अच्छी तरह से करने पर केंद्रित होते हैं।

Answer 3

ध्यान दें कि ऐसा कोई कारण नहीं है कि Microsoft विंडोज के लिए एक शेल लिखने वाला एकमात्र हो सकता है। जो लोग बैश लिखते हैं वे उन लोगों से अलग होते हैं जो * निक्स कर्नेल लिखते हैं। आपको रूट विशेषाधिकारों की भी आवश्यकता नहीं है। मैंने अपने स्वयं के गोले का उपयोग करने के लिए संकलित किया है, जब मैं एक स्थापित sysadmin पसंद नहीं था। अगर एक बेहतर विंडोज शेल की सही मांग थी, तो किसी ने लिखा होगा।

Answer 4

क्योंकि एक के लिए पर्याप्त कॉल नहीं आया है, मुझे लगता है।

विंडोज स्क्रिप्टिंग होस्ट विंडोज 98 के बाद से मानक के रूप में स्थापित किया गया है (मुझे लगता है कि यह उस से पहले के आसपास था); वीबीएसस्क्रिप्ट बहुत सक्षम था; या आप आसानी से एक कमांड-लाइन टूल लिख सकते हैं, जिसकी पहुंच पूरे विंडोज एपीआई तक थी।

Powershell, बस रखा, एक ही दिशा में एक और कदम है। COM किसी भी अधिक लोकप्रिय नहीं है, इसलिए WSH काफी सीखने की प्रक्रिया बन गई है। लेकिन .NET विंडोज दुनिया में वर्तमान बिग थिंग है और .NET पृष्ठभूमि से पॉवर्सशेल सीखना अपेक्षाकृत आसान है।

एक जगह मुझे लगता है कि Powershell गलत हो गया है, हालांकि * nix भीड़ के साथ-साथ अपने सभी उपनामों के साथ अपील करने की कोशिश कर रहा है जो इसे स्पष्ट रूप से नहीं होने पर बैश की तरह दिखते हैं।

कमांडलाइन स्विच के अलावा, पॉवर्सशेल में पाइपिंग बहुत अलग है और वास्तव में पहली चीज है जिसे आपको सीखना चाहिए जब आप इसे उठाते हैं।

और ईमानदारी से, यह एक पटकथा भाषा, एक ला पर्ल, एक खोल, एक ला बैश की तरह बहुत अधिक है। यदि आप इसे अपने प्राथमिक शेल के रूप में उपयोग करने का प्रयास करते हैं, तो कुछ गंभीर गोते हैं।

उदाहरण के लिए, Powershell से एक सरल SVN डंप करने का प्रयास करें। यह बहुत अच्छी तरह से stdout में बाइनरी डेटा को हैंडल नहीं करता है। दूसरी ओर, SVN लॉग में हेरफेर करना एक पूर्ण सपना है, इसके अंतर्निहित xml प्रकार के लिए धन्यवाद।

Comments

मुझे उपनामों से ऐतराज नहीं है, लेकिन मुझे इसके सिंटैक्स में बहुत सारे किनारे मामले पसंद नहीं हैं।

— जॉब

@ जोब: मेरे पास पॉवरशेल के साथ कई मुद्दे हैं, जो कि यहां केवल एक ही उचित लग रहा था। उस ने कहा, पॉवरशेल के बारे में पर्याप्त अच्छी चीजें हैं जो इसे कभी-कभी दर्द के लायक बनाती हैं।

— पीडीआर

+1, VBScript होने से वास्तव में शेल स्क्रिप्टिंग वातावरण की आवश्यकता कई मायनों में समाप्त हो गई।

— व्याट बार्नेट

एक और बात यह है कि विशिष्ट यूनिक्स आईपीसी विंडोज में धीमी गति से और अनाड़ी है। वहां पाइप बेकार हैं।

— एसके-लॉजिक

Answer 5

क्योंकि एक दूसरे समानांतर विंडोज टूलसेट को विकसित करने में बहुत कम जरूरत और बहुत दर्द है।

गन एक जीएनयू सिस्टम पर हेल्पर कार्यक्रमों की संख्या और शक्ति के माध्यम से शक्तिशाली बनाये जाते हैं, जैसे कि sed, find, xargs et al। इन उपकरणों को फिर से लागू करना बहुत काम है, और बस विंडोज के ऊपर एक POSIX अनुपालन परत का निर्माण करना बहुत आसान साबित हुआ है। साइग्विन एक ऐसी POSIX अनुपालन परत है और अधिकांश उपयोगकर्ताओं के लिए शेल प्रदान करता है जब उन्हें विंडोज का उपयोग करने के लिए मजबूर किया जाता है।

मैं व्यक्तिगत रूप से अनुमान लगाऊंगा कि डेवलपर समुदाय, जो पोसिक्स और लिनक्स बैंडवागन को कूदने के लिए तैयार नहीं है और अभी भी शेल प्रोग्रामिंग के लिए पर्याप्त रूप से समर्पित है, एक स्थिर शेल विकसित करने में 20 साल लग गए।

Answer 6

यह उन सवालों में से एक है, जो षड्यंत्र के सिद्धांतों की अनदेखी कर रहे हैं, शायद उनके पास एक भी जवाब नहीं है और इस तरह की बात इतिहासकार हमेशा के लिए एक निश्चित जवाब पाने के बिना बहस कर सकते हैं।

मेरी धारणा है कि शेल की शक्ति तुरंत स्पष्ट नहीं है। मैंने विंडोज 3.1 में प्रोग्रामिंग शुरू की और शेल का बहुत कम उपयोग हुआ। सब कुछ विज़ुअल सी ++ आईडीई के माध्यम से किया गया था, और मैंने कभी भी मेकफाइल्स को नहीं देखा और डॉस बैच फाइलें इतनी सीमित थीं कि मैंने शायद ही कभी बेसिक बैकअप की तुलना में अधिक जटिल कुछ भी स्वचालित करने के लिए बैच फ़ाइल का उपयोग करने की कोशिश की। विंडोज केंद्रित प्रोग्रामिंग पुस्तकों में से कोई भी (मेरे पास पेट्ज़ोल्ड की शौकीन यादें हैं ) मैं उस समय पढ़ रहा था जब किसी चीज़ के लिए विंडोज शेल का उपयोग करके चर्चा की गई थी। जब तक मैंने लिनक्स का उपयोग और प्रोग्रामिंग करना शुरू नहीं किया, तब तक मैं समझ गया था कि एक शक्तिशाली शेल कितना उपयोगी हो सकता है। मुझे याद है जब विंडोज बाहर आया था तो यह बहुत रोमांचक था क्योंकि आपको पुराने का उपयोग नहीं करना थाcommand.comअब और। हम अंततः एक TSR की आवश्यकता के बिना एक से अधिक फ़ॉन्ट और एक ही समय में चल रहे कई कार्यक्रमों के साथ एक सुंदर इंटरफ़ेस था ...

मुझे लगता है कि ज्यादातर प्रोग्रामर जो विंडोज में शुरू करते हैं, उनके पास एक शक्तिशाली शेल के साथ अनुभव नहीं है और इसलिए, विंडोज के लिए एक को लागू करने के लिए दबाव की आवश्यकता महसूस नहीं होती है। प्रोग्रामर जो लिनक्स में काम करते हैं और शेल की सराहना करते हैं, लिनक्स में काम करना पसंद करते हैं और इसलिए ऐसा माहौल में काम करने में समय नहीं लगता है, जो विंडोज के लिए लागू करने में उतना सहज नहीं है, विशेष रूप से विचार (जैसा बताया गया है) एक अन्य प्रश्न में) शेल के साथ ही आवश्यक सभी सीएलआई उपकरणों को भी लागू करने की आवश्यकता है।

लिनक्स की बढ़ती लोकप्रियता, शायद, मुख्य कारण है कि माइक्रोसॉफ्ट ने आखिरकार एक उचित शेल को रखा। जैसा कि अधिक से अधिक लोगों ने महसूस किया कि एक शेल क्या उपयोगी है इसके लिए अधिक से अधिक स्पष्ट हो गया कि विंडोज एक महत्वपूर्ण उपकरण गायब था।

Answer 7

यदि आप यूनिक्स गोले को "सभ्य" मानते हैं, तो विंडोज के लिए कम से कम एक खोल है जो दशकों से "सभ्य" है। हैमिल्टन सी खोल यथोचित पास यूनिक्स C शेल (हालांकि ध्यान दें कि सी खोल यूनिक्स पर विशेष रूप से विशाल बाजार में पैठ था कभी नहीं किया है) है। काफी लोगों ने काफी समय से JPSoft के विभिन्न गोले (4DOS, 4NT, जिसे अब टेक कमांड कहा जाता है) का उपयोग किया है - जैसा कि आप शायद नाम से अनुमान लगा सकते हैं, 4DOS MS-DOS दिनों में वापस चला जाता है।

यदि आप Microsoft द्वारा वितरित शेल पर जोर देते हैं, तो 15 साल पहले या विंडोज एनटी रिसोर्स किट में पीडी कोर्न शेल ^{1 के} एनटी पोर्ट के साथ-साथ उचित संख्या में यूनिक्स-ईश उपयोगिताओं को शामिल किया गया था। इसमें संशोधन के बिना बहुत सारी शेल स्क्रिप्ट चलाने के लिए पर्याप्त रूप से शामिल नहीं किया गया था, लेकिन उचित मात्रा में उपयोग को संभालने के लिए पर्याप्त था, विशेष रूप से काफी इंटरैक्टिव काम।

---

¹ सभी ईमानदारी में, मुझे नहीं पता कि यह उस सटीक शेल का एक बंदरगाह था, या बस कुछ समान था - मैंने इसे सत्यापित करने के लिए पर्याप्त उपयोग किया कि यह उतना ही कष्टप्रद था जितना कि मुझे यूनिक्स के गोले याद थे, और उस पर छोड़ दिया था ।

Comments

चूँकि हम शेल "प्रोग्रामिंग" यहाँ बात कर रहे हैं, तो क्या ऐसा नहीं होना चाहिए "... दुरुपयोग की एक उचित मात्रा को संभालने के लिए पर्याप्त था ..."? :)

— sbi

yay 4DOS - 4DOS (Linux और Unixes पर स्विच करने से पहले) अच्छी यादें ...

— johannes

Answer 8

विंडोज में डिजाइन की विशेषताएं हैं जो स्क्रिप्टिंग के लिए खुद को उधार नहीं देती हैं। यह ग्राफिकल इंटरफ़ेस को ऑपरेशन का प्राथमिक मोड बनाने का एक परिणाम है। कई उपकरणों में कार्यात्मक कमांड लाइन इंटरफेस नहीं है। एक सभ्य कमांड लाइन इंटरफ़ेस के बिना एक अच्छा शेल उत्पन्न करना बहुत मुश्किल है।

अक्सर विंडोज़ में स्क्रिप्ट की जाने वाली चीज़ों के लिए माउस क्लिक और एप्लिकेशन विंडो पर विभिन्न स्थानों पर सिम्युलेटेड कुंजी स्ट्रोक की आवश्यकता होती है। परिणामी स्क्रिप्ट काफी नाजुक हो सकती है। कमांड भाषा में लिपि का वर्णन करना एक तुच्छ अभ्यास नहीं है क्योंकि प्रासंगिक ज्यामिति आसानी से उपलब्ध नहीं है।

विंडोज में शुरुआती संस्करणों में कार्यात्मक पाइपिंग तंत्र भी नहीं था। जैसा कि इसे वर्णित किया गया था, पहली प्रक्रिया चलेगी और इसका आउटपुट अस्थायी फ़ाइल में सहेजा जाएगा। उस फाइल को अगले कमांड के इनपुट के रूप में इस्तेमाल किया जाएगा। यह डिस्क गहन हो सकता है और पर्याप्त अस्थायी स्थान उपलब्ध न होने पर विफल हो जाएगा। यूनिक्स पाइप मेमोरी में डेटा पास करते हैं और प्रक्रियाओं को इस तरह से शेड्यूल करते हैं जो देरी को कम करता है।

Answer 9

जब इसे लॉन्च किया गया था, तो 1993 में, विंडोज़ एनटी एमएस द्वारा अंतरिक्ष में पहले से मौजूद यूनिक्स सर्वरों द्वारा कब्जा कर लिया गया था और उस समय POSIX संगतता और पोर्टेबिलिटी के बारे में एक बड़ा सौदा किया गया था। लेकिन यह काफी काम नहीं करता था - इसके बजाय इसके उपयोगकर्ता बेहतर हार्डवेयर का उपयोग करते हुए डेस्कटॉप की भीड़ थे (ये वे दिन थे जब 32 एमबी रैम के साथ 486dx 50MHz शीर्ष छोर के करीब था) और एक बेहतर ओएस चाहते थे। लेकिन वे गोले में दिलचस्पी नहीं ले रहे थे, जिससे सभी फिसल गए। विंडोज सर्वर 2000 के समय तक, जो इस बाजार को क्रैक करने का एक दूसरा गंभीर प्रयास था, मुझे लगता है कि एमएस ने महसूस किया था कि वे शेल की तरफ कमजोर थे - जैसा कि शेल खोल स्क्रिप्ट को पसंद है - लेकिन फिर भी उन्हें खुजली को खरोंच करने में कुछ समय लगा।