อะไรคือสาเหตุที่ทำให้ Windows ไม่เคยมีเชลล์ที่ดีมาก่อน [ปิด]

ฉันอ่านหัวข้อใน SO: ทำไมภาษาสคริปต์ (เช่น ... ) ไม่เหมาะกับภาษาของเชลล์? . โดยเฉพาะอย่างยิ่งผมชอบคำตอบโดยJörg W MittagWindows PowerShellจากการที่ผมได้เรียนรู้สิ่งที่น่าสนใจเกี่ยวกับ ดังนั้นหลังจากผ่านไปกว่า 20 ปี Windows ก็มีเชลล์ที่ออกแบบมาอย่างดี (Windows 1.0 - 1985, PowerShell เสถียร release - 2009) ในทางตรงกันข้ามระบบ Unix นั้นมีเชลล์จำนวนมากตั้งแต่ปี 1978 Bourne Shell ฉันได้อ่านบทความบางส่วนเกี่ยวกับการสัมภาษณ์งานของ MS และฉันรู้สึกประทับใจกับ บริษัท ที่ "น่ารัก" มาก ฉันสงสัยว่าทำไมพวกเขาถึงไม่ต้องการเครื่องมือบรรทัดคำสั่งเทียบกับคนที่ใช้ระบบปฏิบัติการยูนิกซ์ที่ทำงานด้วยเครื่องมือเหล่านั้น

เหตุผลเดียวกับที่ iPod, iPhone (โทรศัพท์ใด ๆ สำหรับเรื่องนั้น) และ iPad ไม่: บรรทัดคำสั่งไม่ใช่ช่องทางหลักในการโต้ตอบกับผู้ใช้กับคอมพิวเตอร์ใน Windows มันอยู่ใน UNIX หรือ GNU / Linux - นั่นคือเหตุผลว่าทำไมมันจึงโตขึ้น อาร์กิวเมนต์เดียวกันว่าทำไมเดสก์ท็อป linux GUI เป็นขยะนานมากเมื่อเทียบกับ Windows (กลโกงชนิด Mac OS ที่นี่เนื่องจากพวกเขาได้บรรทัดคำสั่ง unix ฟรี)

บางทีฉันอาจจะพูดเกินจริง แต่ฉันคิดว่ามันเป็นวัฒนธรรม:

1. ในวัฒนธรรมของไมโครซอฟท์พัฒนามุ่งเน้นไปที่การเขียนโปรแกรมสำหรับพวกเขาผู้ใช้ โปรแกรมทั้งหมดเป็นแบบ GUI
2. ในวัฒนธรรม Unix, นักพัฒนามุ่งเน้นไปที่การเขียนโปรแกรมอื่น ๆนักพัฒนา โปรแกรมมีขนาดเล็กและมุ่งเน้นการทำสิ่งที่ดี

โปรดทราบว่าไม่มีเหตุผลที่ Microsoft สามารถเป็นคนเดียวในการเขียนเชลล์สำหรับ Windows พวกที่เขียน bash นั้นต่างจากพวกที่เขียน * nix kernels คุณไม่จำเป็นต้องมีสิทธิ์ใช้งานรูท ฉันรวบรวมเปลือกหอยของตัวเองเพื่อใช้เมื่อฉันไม่ชอบที่ดูแลระบบที่ติดตั้ง หากมีความต้องการที่แท้จริงสำหรับเชลล์ Windows ที่ดีกว่าใครบางคนจะเขียนหนึ่งอัน

เพราะไม่เคยมีใครโทรมาหาฉันเลย

Windows Scripting Host ได้รับการติดตั้งเป็นมาตรฐานมาตั้งแต่ Windows 98 (ฉันคิดว่ามันอยู่ก่อนหน้านั้น); VBScript นั้นมีความสามารถมาก หรือคุณสามารถเขียนเครื่องมือบรรทัดคำสั่งได้อย่างง่ายดายซึ่งมีการเข้าถึง Windows API ทั้งหมด

Powershell กล่าวง่ายๆคือเป็นอีกก้าวหนึ่งในทิศทางเดียวกัน COM ไม่ได้รับความนิยมอีกต่อไปดังนั้น WSH จึงกลายเป็นกระบวนการเรียนรู้ แต่. NET เป็นสิ่งที่ยิ่งใหญ่ในโลก Windows และการเรียนรู้ Powershell จากพื้นหลัง. NET นั้นค่อนข้างง่าย

ที่เดียวที่ฉันคิดว่า Powershell ผิดพลาดไปแล้วแม้ว่าจะพยายามดึงดูดฝูงชนที่ชอบ * เช่นกันด้วยนามแฝงทั้งหมดที่ทำให้ดูเหมือน Bash เมื่อไม่ชัดเจน

นอกเหนือจากสวิตช์บรรทัดคำสั่งการวางท่อแตกต่างกันมากใน Powershell และเป็นสิ่งแรกที่คุณควรเรียนรู้เมื่อหยิบขึ้นมา

และจริงๆแล้วมันก็เป็นมากกว่าภาษาสคริปต์ a la Perl มากกว่าเชลล์ a la Bash มี gotchas ที่ร้ายแรงบางอย่างถ้าคุณพยายามที่จะใช้มันเป็นเปลือกหลักของคุณ

ตัวอย่างเช่นลองทำการดัมพ์ SVN แบบง่ายจาก Powershell มันไม่จัดการกับข้อมูลไบนารีใน stdout ได้เป็นอย่างดี ในทางกลับกันการจัดการบันทึก SVN เป็นความฝันที่สมบูรณ์แบบขอบคุณประเภท xml ในตัว

เนื่องจากมีความต้องการน้อยและเจ็บปวดมากในการพัฒนาชุดเครื่องมือ Windows คู่ขนาน

เชลล์มีประสิทธิภาพผ่านจำนวนและพลังของโปรแกรมตัวช่วยบนระบบ GNU เช่น sed, find, xargs และคณะ การนำเครื่องมือเหล่านี้กลับมาใช้ใหม่เป็นงานจำนวนมากและเพียงแค่สร้างเลเยอร์ความสอดคล้อง POSIX ที่ด้านบนของ Windows ได้พิสูจน์แล้วว่าง่ายกว่ามาก Cygwin เป็นเลเยอร์ความสอดคล้อง POSIX และจัดเตรียมสำหรับความต้องการของผู้ใช้เชลล์ส่วนใหญ่เมื่อพวกเขาถูกบังคับให้ใช้ Windows

โดยส่วนตัวฉันจะเดาว่าชุมชนนักพัฒนาที่ทั้งคู่ไม่เต็มใจที่จะกระโดด POSIX และ bandwagon Linux และยังคงอุทิศอย่างเพียงพอกับการเขียนโปรแกรมเชลล์มีขนาดเล็กมากจนใช้เวลา 20 ปีในการพัฒนาเชลล์ที่เสถียร

นี่เป็นหนึ่งในคำถามเหล่านั้นที่ไม่สนใจทฤษฎีการสมคบคิดอาจไม่มีคำตอบเดียวและเป็นสิ่งที่นักประวัติศาสตร์สามารถโต้เถียงกันตลอดไปโดยไม่ต้องค้นหาคำตอบที่ชัดเจน

ความประทับใจของฉันคือพลังของเปลือกไม่ชัดเจนทันที ฉันเริ่มเขียนโปรแกรมใน Windows 3.1 และมีการใช้งานเชลล์น้อยมาก ทุกอย่างดำเนินการผ่าน Visual C ++ IDE และฉันไม่เคยดูไฟล์แบทช์makefilesและ DOS นั้นมีข้อ จำกัด มากจนแทบจะไม่เคยใช้แบตช์ไฟล์เพื่อทำสิ่งที่ซับซ้อนกว่าการสำรองข้อมูลพื้นฐานโดยอัตโนมัติ ไม่มีหนังสือที่เน้นการเขียนโปรแกรม Windows (ฉันมีความทรงจำที่ชอบPetzold ) ฉันกำลังอ่านในเวลาที่กล่าวถึงการใช้เชลล์ Windows เพื่ออะไร มันไม่ได้จนกว่าฉันจะเริ่มใช้และการเขียนโปรแกรมลินุกซ์ที่ฉันเข้าใจว่าเปลือกที่มีประสิทธิภาพอาจมีประโยชน์ ฉันจำได้ว่าเมื่อ Windows ออกมามันน่าตื่นเต้นมากเพราะคุณไม่ต้องใช้เก่าcommand.comอีกต่อไป ในที่สุดเราก็มีส่วนต่อประสานที่สวยงามพร้อมด้วยตัวอักษรมากกว่าหนึ่งตัวและหลายโปรแกรมทำงานพร้อมกันโดยไม่จำเป็นต้องใช้TSR ...

ฉันคิดว่าโปรแกรมเมอร์ส่วนใหญ่ที่เริ่มต้นใน Windows ไม่มีประสบการณ์กับเชลล์ที่ทรงพลังดังนั้นไม่รู้สึกว่าจำเป็นต้องมีการใช้งานสำหรับ Windows โปรแกรมเมอร์ที่ทำงานใน Linux และชื่นชมเชลล์ชอบทำงานใน Linux จึงไม่รู้สึกอยากใช้เวลาทำงานในสภาพแวดล้อมที่ไม่สะดวกในการใช้งานหนึ่งสำหรับ Windows โดยเฉพาะเมื่อพิจารณาแล้ว ในคำถามอื่น) ความจำเป็นที่จะต้องใช้เครื่องมือ CLI ทั้งหมดที่จำเป็นพร้อมกับเชลล์ด้วย

ความนิยมที่เพิ่มขึ้นของลีนุกซ์อาจเป็นเหตุผลหลักที่ในที่สุดไมโครซอฟท์ได้วางเชลล์ที่เหมาะสมในขณะที่ผู้คนจำนวนมากตระหนักว่าเชลล์มีประโยชน์สำหรับมันมากขึ้นเรื่อย ๆ และชัดเจนว่า Windows หายไปเป็นเครื่องมือสำคัญ

หากคุณพิจารณากระสุน Unix ว่า ​​"เหมาะสม" แสดงว่ามีเชลล์อย่างน้อยหนึ่งตัวสำหรับ Windows ที่ "ดี" มานานหลายทศวรรษ แฮมิลตัน C เปลือกเป็นเหตุผลใกล้เคียงกับระบบปฏิบัติการยูนิกซ์ C เปลือก (แม้ว่าจะทราบว่า C เปลือกไม่เคยมีส่วนแบ่งการตลาดมากโดยเฉพาะอย่างยิ่งบน Unix) มีคนไม่กี่คนที่ใช้เปลือกหอยต่าง ๆ ของ JPSoft (4DOS, 4NT ซึ่งปัจจุบันเรียกว่า Take Command) มาสักพักหนึ่ง - เพราะคุณอาจเดาได้จากชื่อ 4DOS กลับไปสู่ยุค MS-DOS

หากคุณยืนยันบนเชลล์ที่จำหน่ายโดย Microsoft เมื่อ 15 ปีก่อนหรือมากกว่านั้นชุดทรัพยากร Windows NT ที่ใช้ในการรวมพอร์ต NT ของเชลล์ Korn PD ¹พร้อมด้วยยูทิลิตี้ Unix-ish หมายเลขยุติธรรม อาจไม่เพียงพอที่จะเรียกใช้เชลล์สคริปต์จำนวนมากโดยไม่มีการดัดแปลง แต่ก็เพียงพอที่จะรองรับปริมาณการใช้งานที่เหมาะสมโดยเฉพาะอย่างยิ่งการทำงานแบบโต้ตอบเล็กน้อย

¹ในความซื่อสัตย์ทั้งหมดฉันไม่รู้ว่ามันเป็นพอร์ตของเชลล์ที่แน่นอนนั้นหรือสิ่งที่ค่อนข้างคล้ายกัน - ฉันใช้มันมากพอที่จะตรวจสอบว่ามันน่ารำคาญเท่าที่ฉันจำได้ว่าเชลล์ Unix เป็นและทิ้งมันไว้ที่ .

Windows มีคุณสมบัติการออกแบบที่ไม่ให้ยืมตัวเองกับการสคริปต์ นี่คือผลลัพธ์ของการทำให้ส่วนต่อประสานกราฟิกเป็นโหมดหลักของการทำงาน เครื่องมือจำนวนมากไม่มีอินเตอร์เฟสบรรทัดคำสั่งที่ใช้งานได้ หากไม่มีอินเตอร์เฟสบรรทัดคำสั่งที่เหมาะสมจะเป็นการยากที่จะสร้างเชลล์ที่ดี

บ่อยครั้งสิ่งที่จำเป็นต้องมีสคริปต์ใน Windows จำเป็นต้องมีการคลิกเมาส์และการกดแป้นเพื่อจำลองที่ตำแหน่งต่างๆในหน้าต่างแอปพลิเคชัน สคริปต์ที่ได้นั้นค่อนข้างบอบบาง การอธิบายตำแหน่งที่สคริปต์ในภาษาคำสั่งไม่ใช่แบบฝึกหัดเล็กน้อยเนื่องจากรูปทรงเรขาคณิตที่เกี่ยวข้องนั้นไม่พร้อมใช้งาน

Windows ยังไม่มีกลไกการทำงานของ piping ในเวอร์ชันก่อนหน้านี้ ตามที่ได้อธิบายไว้แล้วว่ากระบวนการแรกจะทำงานและผลลัพธ์ของมันจะถูกบันทึกลงในไฟล์ชั่วคราว ไฟล์นั้นจะถูกใช้เป็นอินพุตไปยังคำสั่งถัดไป นี่อาจเป็นดิสก์ที่เข้มข้นและจะล้มเหลวหากไม่มีที่ว่างชั่วคราวเพียงพอ ท่อยูนิกซ์ส่งผ่านข้อมูลในหน่วยความจำและกำหนดเวลากระบวนการในลักษณะที่ลดความล่าช้าให้น้อยที่สุด

เมื่อเปิดตัวในปี 1993 Windows NT เป็นการย้ายโดย MS ไปยังพื้นที่ที่ครอบครองโดยเซิร์ฟเวอร์ Unix ก่อนหน้านี้และในเวลานั้นมีเรื่องสำคัญเกี่ยวกับ POSIX ที่เข้ากันได้และการพกพา แต่มันก็ไม่ค่อยได้ผลนัก - แทนที่จะเป็นกลุ่มผู้ใช้เดสก์ท็อปที่ใช้ฮาร์ดแวร์ที่ดีกว่า (นี่คือช่วงเวลาที่ 486dx 50MHz พร้อม RAM ขนาด 32MB ใกล้ระดับบนสุด) และต้องการระบบปฏิบัติการที่ดีกว่า แต่พวกเขาไม่สนใจเปลือกหอยดังนั้นทั้งหมดจึงลื่น เมื่อถึงเวลาของ Windows Server 2000 ซึ่งเป็นความพยายามครั้งที่สองที่จะเจาะตลาดนี้ฉันคิดว่า MS รู้ว่าพวกเขาอ่อนแอด้านเชลล์ - ในฐานะผู้ดูแลระบบรักสคริปต์เชลล์ - แต่ถึงอย่างนั้นก็ต้องใช้เวลาสักพักในการเกา