Mengapa bash shell default di sebagian besar OS?


38

Mengapa bash shell default di sebagian besar OS (Ubuntu, Fedora, OSX, dll.)? Mengapa banyak pengguna tingkat lanjut sebagian besar menggunakan zsh? Jika sehebat itu, mengapa itu tidak baku?

Saya menggunakan keduanya, saya tidak melihat perbedaan karena semua tugas saya sederhana :)


5
Semuanya adalah kurva Gaussian: jika benar bahwa sebagian besar pengguna tingkat lanjut menggunakan ksh, maka juga benar bahwa kebanyakan orang menggunakan shell yang berbeda, dan ini dengan sendirinya akan menjelaskan mengapa kshbukan shell default. Namun saya tidak berpikir itu alasannya, mari kita tunggu jawaban pembunuh yang saya yakin pertanyaan ini akan terima.
kos

1
Sebenarnya, saya percaya ubuntu menggunakan dasbor sebagai shell default ...
Bakuriu

1
Ini memiliki jawaban yang bagus, saya memilih kita membiarkannya terbuka.
Seth

Jawaban:


33

Saya melakukan beberapa bacaan tentang ini dan kesimpulannya sepertinya itu adalah shell default dari GNU (digunakan oleh sebagian besar OS berbasis Linux), dan oleh karena itu hanya dikemas sebagai bagian dari GNU, sementara juga memiliki 20 tahun pengembangan di belakangnya membuatnya menjadi stabil dan berpengetahuan luas, ini hanyalah yang terbaik serba bisa, memenuhi kebutuhan semua orang kecuali pengguna yang paling canggih.

Untuk lebih lanjut, baca Mengapa standar bash di Linux? (pertanyaan yang sama di Unix & Linux).

Hanya untuk menambahkan sedikit lebih banyak ke ini, ada banyak kerang lain untuk dicoba, jika Anda tertarik, berikut beberapa dari jawaban ini :

  • Zsh memiliki fasilitas interaktif yang lebih canggih, tetapi beberapa keanehan dalam hal scripting (kurang begitu sekarang daripada saat ini). Pada awal hingga pertengahan 1990-an ketika Linux masih dalam masa pertumbuhan, zsh sebenarnya tidak dikenal.

  • Ksh adalah standar de facto pada kesatuan komersial sejak pertengahan 1980-an, tetapi itu adalah perangkat lunak berpemilik sampai tahun 2000, jadi bukan pilihan di Linux. Juga, ksh memiliki kemampuan mengedit baris perintah di bawah standar, dibandingkan dengan bash.

  • Pdksh , klon ksh gratis, akan menjadi pilihan, tetapi itu tidak dikenal dan memiliki kemampuan edisi baris perintah yang buruk. (Pdksh bukan lagi proyek yang sangat aktif, meskipun masih digunakan di beberapa BSD, sekarang ATT ksh gratis.)

  • Beberapa distribusi memasang varian abu sebagai /bin/sh. Ash (yang saya maksudkan salah satu keluarga kerang longgar yang disebut ash) dirancang untuk menjadi kecil dan cepat, tanpa fitur interaktif (hanya untuk mengedit skrip). Kebangkitan abu relatif baru; pada 1990-an varian yang ada tidak memiliki banyak fitur.

  • Tcsh adalah shell interaktif paling canggih sampai zsh datang, tapi itu tidak kompatibel dengan sh dan tidak begitu baik dengan skrip .


1
Ketika Anda menyalin-menempelkan sesuatu dari tempat lain, Anda seharusnya menunjukkan dengan jelas bahwa ini adalah masalahnya.
muru

1
@muru Saya memang memberikan tautan ke posting asli, tapi saya mengerti maksud Anda bahwa itu bisa lebih jelas.
Mark Kirby

Apa sumber komentar Anda bahwa zsh memiliki beberapa kebiasaan sehubungan dengan scripting? Sudahlah, saya melihat bahwa komentar itu datang dari tempat lain.
Scooter

1
Anda juga memiliki ikan (yang tidak sesuai dengan sintaks sh).
Léo Lam

1
Bisakah Anda menjelaskan apa yang kurang tentang pengeditan shell Korn? Tampaknya selalu berhasil bagi saya, bahkan di tahun 90-an.
Jonathan Leffler

9

The Bourne Shell ( sh kembali pada hari) dari AT & T cabang Unix itu diperbaiki dan diganti oleh Korn Shell, ksh . ksh juga keluar dari AT&T Bell Labs dan bukan GPL (versi saat ini adalah Eclipse Public License). C-shell, csh keluar dari Unix versi Berkeley dan juga bukan GPL (lisensi BSD) dan juga menggunakan sintaks yang berbeda dari sh. Z-shell, zsh adalah peningkatan pada sh tetapi bukan GPL (lisensi mirip MIT). Bash merupakan perbaikan pada sh, menggunakan GPL dan dari GNU. Hanya pada lisensi saja Bash mungkin akan menjadi pilihan untuk sistem operasi GPL. Terutama dengan shell yang menjadi bagian inti dari sebuah distro.

Tetapi Bash juga merupakan proyek GNU, memberikannya, saya pikir, pengembangan yang lebih aktif dan membuat kontribusi lebih mudah daripada produk warisan dari Berkeley Unix atau AT&T Unix. Sebuah kasus yang sangat bagus dapat dibuat bahwa zsh adalah dan telah menjadi shell yang lebih baik daripada Bash, tetapi tidak cukup untuk mengatasi perbedaan lisensi dan status proyek non-GNU.

Kembali ketika distro Linux pertama kali muncul dan memilih shell default mereka (awal hingga pertengahan 90-an), tidak ada github (2008) atau bahkan SourceForge (1999). Pada saat itu, saya pikir proyek-proyek GNU memiliki keuntungan nyata dibandingkan proyek-proyek non-GNU dalam mendapatkan perhatian dan menggambar dan termasuk pengembang baru. Jadi distro dapat melihat Z-shell sebagai lebih baik, tetapi juga berharap bahwa Bash akan mendapatkan dukungan dan pemeliharaan yang baik ke depan, dan juga memiliki lebih banyak fitur yang ditambahkan padanya, memungkinkannya untuk mengejar zsh.

Sekarang Bash telah memiliki status default bertahun-tahun, itu menjadi standar de facto, dengan buku-buku yang ditulis tentangnya. Ada satu buku yang mencakup Bash dan Z-shell , tetapi tidak ada buku yang membahasnya secara eksklusif, sementara ada banyak buku yang melakukannya untuk Bash.

Dan pada titik ini, jika distro mengubah default untuk peningkatan sistem yang ada, itu akan merusak pengaturan karena beberapa file inisialisasi memiliki nama yang berbeda (misalnya .bashrc versus .zshrc) dan konten file mungkin memiliki sintaksis yang tidak kompatibel. Jadi mereka akan sangat enggan untuk melakukan itu, meninggalkan unduhan baru memiliki zsh sebagai default dan memutakhirkan untuk memiliki bash. Dua default berbeda untuk distro yang sama adalah sesuatu yang mereka mungkin tidak ingin harus mendukung dan pengguna / perusahaan juga tidak mau berurusan dengan itu.


1

Bahasa shell Unix semuanya jelek. Beberapa khususnya ( csh), beberapa mungkin sedikit kurang ( ksh? Saya tidak tahu sebenarnya), tetapi sebenarnya ketika datang ke aspek-aspek seperti keterbacaan dan kekakuan untuk proyek-proyek besar, tidak satupun dari mereka bisa mendekati bahasa tujuan umum yang dirancang dengan baik seperti Python, C # atau Haskell. Jadi, ketika Anda menginginkan sesuatu yang solid, Anda tidak akan pernah memilih salah satu rasa shell sama sekali.

Anda memang memilih mereka ketika Anda ingin cepat menyelesaikan hal-hal sederhana. Untuk ini, Anda perlu:

  • Sintaksis ringkas, dan konsistensi yang cukup sehingga Anda dapat benar-benar menghafalnya (sulit untuk mencari operator singkatan). Sangat penting jika cangkang Anda dipasang di mana-mana, karena Anda lebih suka tidak akan menghafal lebih dari satu monster kludge ini.
  • Fitur interaktif yang bagus, sehingga Anda dapat meretas langsung ke terminal dan membuat barang berfungsi tanpa harus beralih di antara banyak file skrip.
  • Kemampuan untuk mengambil cuplikan skrip apa pun dari mana saja dan membuatnya hanya berfungsi. shkompatibilitas adalah nilai tambah besar di sini, dan sekali lagi semakin populer semakin baik.

Jadi Anda tahu, popularitas adalah poin yang lebih besar dalam bahasa shell ini daripada untuk bahasa tujuan umum. Oleh karena itu bahkan jika kshsedikit lebih baik sebagai bahasa itu sendiri, tidak ada begitu banyak keuntungan dalam menggunakannya jika bashhanya sedikit lebih populer (yang, di sektor yang relevan, karena pertama kali dipilih sebagai default untuk GNU).

Orang-orang yang melakukan peralihan disengaja dan cukup berpengalaman untuk dengan mudah menangani peralihan ke cangkang favorit mereka. OTOH, seorang pemula yang dipaksa untuk bekerja dengan shell yang kurang populer akan cepat bingung jika mereka meminta sesuatu di internet dan itu tidak berhasil. Oleh karena itu, setiap distro yang tidak hanya ditujukan untuk veteran Unix mengambil risiko yang cukup besar jika membuat apa pun selain bashstandar, sebuah langkah di mana relatif sedikit orang akan mendapat manfaat (dan hanya sedikit).


1
Bahasa apa pun yang peduli tentang jumlah spasi putih tidak "dirancang dengan baik", tapi saya setuju bahwa popularitas adalah kuncinya.
Nagora

1
@ Nagora: pendapat berbeda-beda. FWIW, Anda selalu dapat menulis Haskell dengan kawat gigi dan titik koma alih-alih spasi putih, dan saya kira Python memiliki fallback yang serupa. Hanya saja, tidak ada yang melakukan ini, karena pengelompokan berbasis indentasi luar biasa untuk dibaca.
leftaroundtentang

1
  1. Itu ada di sana ketika dibutuhkan
  2. Ini memiliki eye candy yang cukup sehingga pengguna pemula dapat menghabiskan seminggu menyesuaikan permintaan mereka.
  3. Kasus penggunaan umum itu cukup baik (yang paling umum memulai perintah tunggal)
  4. Di mana itu perl tidak cukup baik, python dan lua dapat mengambil kendur.
  5. perl membuat shell interaktif yang mengerikan
  6. meskipun ikan, ksh atau zsh secara teoritis bisa menjadi cangkang yang lebih baik tidak ada cukup perbaikan bagi saya untuk mengganggu ketika perl bekerja dengan baik atau portabilitas adalah masalah jadi saya tetap menargetkan dash.

0

"Massa Kritis" adalah jawaban utama, IMO. Bash bukan hanya untuk pekerjaan baris perintah, tetapi juga untuk scripting dan ada banyak sekali skrip Bash di luar sana. Tidak peduli seberapa jauh alternatif yang lebih baik sekarang untuk interaksi, kebutuhan untuk dapat "plug and play" skrip-skrip tersebut lebih besar daripada keuntungannya. Dengan demikian, satu-satunya shell yang secara realistis dapat menggeser Bash sekarang adalah yang benar-benar kompatibel dengan mundur dan kandidat yang paling mungkin untuk itu adalah ... versi Bash berikutnya.


1
Anda dapat menggunakan skrip bash apa saja dan semua sebagaimana apa pun shell default Anda. Itulah arti she-bang (#! / Bin / bash) di bagian atas skrip.
Panther

1
@ bodhi.zazen Selama bash shell ada di sistem. Saya sudah tahu setidaknya versi Solaris yang tidak menyertakan bash.
Tulains Córdova

@ bodhi.zazen Ada biaya mental karena harus beralih antara dua shell - satu untuk interaksi dan satu untuk skrip. Ini umumnya tidak layak untuk diganggu.
Nagora

1
@ Nagora Berapa biaya mental menjalankan skrip?
kos

@kos jika Anda benar-benar hanya menjalankan skrip, tidak ada. Jika Anda harus memelihara dan mengadaptasi skrip maka Anda harus selalu mengingat perbedaan yang cukup kecil antara cangkang yang berbeda, dalam hal ini ada biaya logam berkelanjutan dan biaya pengalihan konteks ketika Anda harus melakukan beberapa pekerjaan di Sintaks "lainnya".
Nagora
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.