Apa alasan mengapa Windows tidak pernah memiliki shell yang layak? [Tutup]


19

Saya membaca topik di SO: Mengapa bahasa scripting (mis. ...) tidak cocok sebagai bahasa shell? . Terutama saya menyukai jawaban oleh Jörg W Mittag , dari mana saya belajar hal-hal menarik Windows PowerShell. Jadi setelah lebih dari 20 tahun Windows akhirnya memiliki cangkang yang dirancang dengan baik (Windows 1.0 - 1985, PowerShell stable release - 2009). Di sisi lain sistem Unix memiliki banyak shell yang berbeda sejak tahun 1978 Bourne Shell. Saya telah membaca beberapa artikel tentang wawancara kerja MS dan saya mendapat kesan perusahaan yang sangat "geekish". Saya bertanya-tanya mengapa mereka tidak membutuhkan alat-alat command-line dibandingkan dengan orang-orang Unix yang melakukan semua pekerjaan mereka dengan alat-alat itu.


@ JerryCoffin, mungkin tergantung berapa lama Anda berada di industri ini. Saya baru mulai di sini jadi saya cukup senang dengan semua perangkat lunak hebat yang diberikan untuk saya. Ada tempat untuk perbaikan besar tetapi akan selalu demikian.
Ski

Jawaban:


16

Alasan yang sama dengan iPod, iPhone (telepon apa pun), dan iPad tidak: baris perintah bukanlah saluran utama interaksi pengguna dengan komputer di Windows. Itu ada di UNIX atau GNU / Linux - jadi itu sebabnya mereka lebih matang. Argumen yang sama mengapa desktop linux GUI adalah sampah begitu lama dibandingkan dengan Windows (Mac OS jenis curang di sini karena mereka mendapat baris perintah unix agak gratis).


13

Mungkin saya terlalu menyederhanakan, tapi saya menganggapnya sebagai hal budaya:

  1. Dalam budaya Microsoft, pengembang fokus pada penulisan program untuk penggunanya . Semua program berbasis GUI.
  2. Dalam budaya Unix, pengembang fokus pada program penulisan untuk pengembang lain . Program-programnya kecil dan fokus untuk melakukan hal tertentu dengan baik.

9

Perhatikan bahwa tidak ada alasan bahwa Microsoft dapat menjadi satu-satunya yang menulis shell untuk Windows. Orang yang menulis bash berbeda dari orang yang menulis kernel * nix. Anda bahkan tidak memerlukan hak akses root. Saya telah mengkompilasi shell saya sendiri untuk digunakan ketika saya tidak suka yang diinstal sysadmin. Jika ada permintaan sejati untuk shell Windows yang lebih baik, seseorang pasti telah menulisnya.


7

Karena tidak pernah ada panggilan cukup untuk satu, saya kira.

Windows Scripting Host telah diinstal sebagai standar sejak Windows 98 (saya menganggap sudah ada sebelumnya); VBScript sangat mampu; atau Anda dapat dengan mudah menulis alat baris perintah, yang memiliki akses ke seluruh API Windows.

Sederhananya, Powershell, hanyalah langkah lain ke arah yang sama. COM tidak populer lagi, jadi WSH telah menjadi proses pembelajaran yang cukup. Tapi .NET adalah Big Thing saat ini di dunia Windows dan belajar Powershell dari latar belakang. NET relatif mudah.

Satu tempat yang saya pikir Powershell salah meskipun dalam mencoba untuk menarik kerumunan * nix juga, dengan semua alias yang membuatnya terlihat seperti Bash ketika jelas tidak.

Terlepas dari saklar commandline, perpipaan sangat berbeda di Powershell dan benar-benar hal pertama yang harus Anda pelajari ketika Anda mengambilnya.

Dan jujur, itu lebih seperti bahasa scripting, a la Perl, daripada shell, a la Bash. Ada beberapa gotcha serius jika Anda mencoba menggunakannya sebagai kulit utama Anda.

Misalnya, coba lakukan dump SVN sederhana dari Powershell. Itu tidak menangani data biner di stdout dengan sangat baik. Di sisi lain, memanipulasi log SVN adalah mimpi mutlak, berkat tipe xml bawaannya.


Saya tidak keberatan dengan alias, tapi saya tidak suka terlalu banyak kasus tepi dalam sintaksnya.
Pekerjaan

@ Pekerjaan: Saya punya banyak masalah dengan Powershell, yang sepertinya satu-satunya yang relevan di sini. Yang mengatakan, ada cukup banyak hal baik tentang Powershell untuk membuatnya sepadan dengan rasa sakit kadang-kadang.
pdr

+1, memiliki VBScript benar-benar menghilangkan kebutuhan untuk lingkungan skrip shell dalam banyak cara.
Wyatt Barnett

Hal lain adalah IPC unix yang khas sangat lambat dan kikuk di Windows. Pipa tidak berharga di sana.
SK-logic

6

Karena ada sedikit kebutuhan dan banyak rasa sakit dalam mengembangkan perangkat Windows paralel kedua.

Kerang dibuat kuat melalui jumlah dan kekuatan program pembantu pada sistem GNU, seperti sed, find, xargs et al. Menerapkan kembali alat-alat ini adalah banyak pekerjaan, dan hanya membangun lapisan kepatuhan POSIX di atas Windows telah terbukti jauh lebih mudah. Cygwin adalah lapisan kepatuhan POSIX dan menyediakan untuk sebagian besar kebutuhan pengguna shell ketika mereka dipaksa untuk menggunakan Windows.

Saya pribadi akan menebak bahwa komunitas pengembang yang tidak mau untuk ikut-ikutan POSIX dan Linux dan masih cukup dikhususkan untuk pemrograman shell sangat kecil sehingga butuh 20 tahun untuk mengembangkan shell yang stabil.


6

Ini adalah salah satu pertanyaan yang, mengabaikan teori konspirasi, mungkin tidak memiliki jawaban tunggal dan merupakan hal yang dapat diperdebatkan oleh sejarawan selamanya tanpa pernah menemukan jawaban yang pasti.

Kesan saya adalah bahwa kekuatan shell tidak segera terlihat. Saya memulai pemrograman pada Windows 3.1 dan penggunaan shell sangat sedikit. Semuanya dilakukan melalui Visual C ++ IDE, dan saya tidak pernah melihat makefiles dan file batch DOS sangat terbatas sehingga saya jarang mencoba menggunakan file batch untuk mengotomatisasi sesuatu yang lebih rumit daripada backup dasar. Tidak ada buku pemrograman yang berfokus pada Windows (saya punya kenangan indah tentang Petzold ) yang saya baca pada saat itu dibahas menggunakan shell Windows untuk apa pun. Baru setelah saya mulai menggunakan dan memprogram Linux saya mengerti betapa berharganya shell yang kuat. Saya ingat ketika Windows keluar itu sangat menarik karena Anda tidak harus menggunakan yang lamacommand.comlagi. Kami akhirnya memiliki antarmuka yang cantik dengan lebih dari satu font dan beberapa program berjalan pada saat yang sama tanpa perlu TSR ...

Saya pikir sebagian besar programmer yang memulai di Windows tidak memiliki pengalaman dengan shell yang kuat dan karenanya, tidak merasakan kebutuhan mendesak untuk mengimplementasikannya untuk Windows. Programmer yang bekerja di Linux dan menghargai shell, lebih suka bekerja di Linux sehingga tidak merasa cenderung menghabiskan waktu bekerja di lingkungan yang tidak nyaman untuk mengimplementasikannya untuk Windows, terutama mengingat (seperti yang telah ditunjukkan dalam pertanyaan lain) kebutuhan untuk juga mengimplementasikan semua alat CLI yang dibutuhkan bersama dengan shell itu sendiri.

Meningkatnya popularitas Linux, mungkin, alasan utama Microsoft akhirnya menempatkan shell yang tepat. Karena semakin banyak orang menyadari apa shell berguna untuk itu menjadi semakin jelas bahwa Windows kehilangan alat penting.


5

Jika Anda menganggap shell Unix "layak", maka sudah ada setidaknya satu shell untuk Windows yang "layak" selama beberapa dekade. The Hamilton C shell cukup dekat dengan Unix C shell (meskipun diketahui bahwa C shell tidak pernah memiliki penetrasi pasar terutama besar pada Unix). Beberapa orang juga telah menggunakan berbagai cangkang JPSoft (4DOS, 4NT, sekarang disebut Take Command) untuk beberapa waktu - seperti yang mungkin Anda tebak dari namanya, 4DOS kembali ke masa MS-DOS.

Jika Anda bersikeras pada shell yang didistribusikan oleh Microsoft, sekitar 15 tahun yang lalu atau sekitar Windows NT Resource kit biasanya menyertakan port NT dari PD Korn shell 1 , bersama dengan sejumlah utilitas Unix-ish. Itu mungkin tidak termasuk cukup untuk menjalankan banyak skrip shell tanpa modifikasi, tetapi cukup untuk menangani cukup banyak penggunaan, terutama cukup banyak pekerjaan interaktif.


1 Dalam semua kejujuran, saya tidak tahu bahwa itu adalah port dari shell yang tepat itu, atau hanya sesuatu yang sangat mirip - saya menggunakannya cukup untuk memverifikasi bahwa itu sama menjengkelkannya dengan saya mengingat shell Unix sedang, dan membiarkannya begitu saja .


Karena kita sedang berbicara shell "pemrograman" di sini, bukankah itu harus "... sudah cukup untuk menangani cukup banyak penyalahgunaan ..."? :)
sbi

yay 4DOS - Saya benar-benar bingung ketika pertama kali saya harus menggunakan shell default MSFT setelah tumbuh dengan 4DOS (sebelum beralih ke Linux dan Unix) kenangan yang baik ...
johannes

5

Windows memiliki fitur desain yang tidak memungkinkan untuk skrip. Ini adalah hasil dari membuat antarmuka grafis mode operasi utama. Banyak alat tidak memiliki antarmuka baris perintah fungsional. Tanpa antarmuka baris perintah yang layak sangat sulit untuk menghasilkan shell yang baik.

Seringkali hal-hal yang perlu ditulis dalam Windows memerlukan klik mouse dan stroke kunci untuk disimulasikan di berbagai lokasi pada jendela aplikasi. Script yang dihasilkan bisa sangat rapuh. Menjelaskan tempat menulis skrip dalam bahasa perintah bukan latihan sepele karena geometri yang relevan tidak tersedia.

Windows juga tidak memiliki mekanisme perpipaan fungsional di versi awal. Seperti yang dijelaskan, proses pertama akan berjalan dan hasilnya akan disimpan ke file sementara. File itu akan digunakan sebagai input ke perintah selanjutnya. Ini bisa menjadi disk intensif dan akan gagal jika ruang sementara yang cukup tidak tersedia. Pipa Unix melewatkan data dalam memori dan menjadwalkan proses dengan cara yang meminimalkan penundaan.


1

Ketika diluncurkan, pada tahun 1993, Windows NT adalah langkah oleh MS ke ruang yang sebelumnya ditempati oleh server Unix dan pada saat itu masalah besar dibuat tentang kompatibilitas dan portabilitas POSIX. Tapi itu tidak cukup melakukan pekerjaan - sebaliknya para penggunanya lebih banyak orang desktop yang menggunakan perangkat keras yang lebih baik (ini adalah hari-hari ketika 486dx 50MHz dengan 32MB RAM dekat dengan ujung atas) dan menginginkan OS yang lebih baik. Tetapi mereka tidak tertarik dengan kerang, sehingga semuanya tergelincir. Pada saat Windows Server 2000, yang merupakan upaya serius kedua untuk memecahkan pasar ini saya pikir MS telah menyadari bahwa mereka lemah di sisi shell - sebagai admin suka shell script - tetapi bahkan kemudian butuh beberapa waktu untuk menggaruk gatal.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.