Bash neden çoğu işletim sisteminde varsayılan kabuktur?


38

Bash neden çoğu işletim sistemindeki varsayılan kabuktur (Ubuntu, Fedora, OSX, vb.)? Neden birçok gelişmiş kullanıcı çoğunlukla zsh kullanıyor? Bu kadar iyiyse neden varsayılan değil?

İkisini de kullanıyorum tüm işlerim için bir fark görmüyorum basit :)


5
Her şey bir Gauss eğrisidir: en gelişmiş kullanıcıların kullandığı doğruysa ksh, o zaman çoğu insanın farklı bir kabuk kullandığı da doğrudur ve bu kendi başına neden kshvarsayılan kabuk olmadığını açıklar . Ancak bunun nedeni olduğunu sanmıyorum, bu sorunun alacağından emin olduğum bazı katil cevapları bekleyelim.
kos

1
Aslında,
ubuntu'nun

1
Bunun iyi bir cevabı var, oyu açık bırakıyoruz.
Seth

Yanıtlar:


33

Bununla ilgili bazı okumalar yaptım ve sonuç, GNU'nun varsayılan kabuğudur (çoğu Linux tabanlı işletim sistemi tarafından kullanılıyor) ve bu nedenle bunun arkasında 20 yıllık bir gelişme varken GNU'nun bir parçası olarak paketlenmiş olarak geliyor. Sağlam ve iyi yuvarlanmış, en gelişmiş kullanıcıların hepsinin ihtiyaçlarını karşılayan, sadece en iyisidir.

Daha fazla bilgi için, neden bash Linux'ta standart? (Unix ve Linux'ta aynı soru).

Sadece buna biraz daha eklemek için, denemek için bir çok mermi var, ilgileniyorsanız, işte bu cevaptan birkaçı :

  • Zsh , daha gelişmiş etkileşimli olanaklara sahiptir, ancak komut dosyası oluşturma konusunda birkaç tuhaflık vardır (günlerden çok daha az şimdi). Linux'un bebeklik döneminde olduğu 1990'ların ortalarında, zsh neredeyse bilinmiyordu.

  • Ksh , 1980'lerin ortasından beri ticari birliklerde fiili bir standarttı, ancak 2000 yılına kadar tescilli bir yazılımdı, Linux'ta bir seçenek değildi. Ayrıca, ksh, bash ile karşılaştırıldığında subpar komut satırı düzenleme yeteneklerine sahipti.

  • Ücretsiz bir ksh klonu olan Pdksh bir seçenek olabilirdi, ancak iyi tanınmıyordu ve komut satırı düzenleme yetenekleri zayıftı. (Pdksh artık çok aktif bir proje değil, hala bazı BSD'lerde kullanılmasına rağmen, şimdi ATT ksh ücretsiz.)

  • Bazı dağıtımlarda olduğu gibi bir kül değişkeni kurar /bin/sh. Kül (yani, kül adı verilen gevşek kabukları ailesinden herhangi birini kastediyorum), etkileşimli özellikleri olmayan (yalnızca komut dosyalarını düzenlemek için) küçük ve hızlı olacak şekilde tasarlanmıştır. Kül canlanması nispeten yenidir; 1990'larda mevcut değişkenlerin pek çok özelliği yoktu.

  • Tcsh , zsh gelinceye kadar en gelişmiş etkileşimli kabuktu , ancak sh ile uyumsuz ve komut dosyasıyla iyi değil .


1
Başka yerlerden şeyleri kopyalayıp yapıştırdığınızda, durumun bu olduğunu açıkça belirtmeniz gerekir.
muru

1
@muru Asıl gönderiye bağlantıyı sağladım, ancak konunun daha net olabileceğini anladım.
Mark Kirby,

Yorumunuzun kaynağı nedir zsh, komut dosyası ile ilgili birkaç tuhaflık var? Aldırma, yorumun başka bir yerden geldiğini gördüm.
Scooter

1
Ayrıca balık (sh sözdizimi ile uyumsuz) var.
Léo Lam,

1
Korn kabuğu düzenlemesiyle ilgili eksiklikleri açıklar mıydınız? 90'lı yıllarda bile, benim için her zaman yolunda gibiydi.
Jonathan Leffler,

9

Bourne Kabuk ( sh Unix, AT & T dalın geri gün) üzerine geliştirilmiş ve Korn kabuk tarafından superceded ksh . ksh ayrıca AT&T Bell Labs'ten çıktı ve GPL değildi (şu anki sürüm Eclipse Public License). C-shell, csh , Unix'in Berkeley versiyonundan çıktı ve aynı zamanda GPL (BSD lisansı) değildi ve ayrıca sh'dan farklı bir sözdizimi kullandı. Z kabuğu, zsh , sh üzerinde bir gelişmedir ancak GPL'ye (MIT benzeri lisans) gelmez. Bash sh üzerinde bir gelişme oldu, GPL'yi ve GNU'yu kullandı. Sadece lisansta Bash muhtemelen bir GPL işletim sistemi için bir seçim olacaktır. Özellikle bir kabuğun bir dağıtımın çekirdek parçası olmasıyla.

Ancak Bash aynı zamanda bir GNU projesiydi, bence, daha aktif bir gelişme ve Berkeley Unix veya AT&T Unix'ten eski bir üründen daha kolay bir şekilde katkıda bulunmak. Zsh'nin Bash'ten daha iyi bir kabuk olduğu ve daha iyi bir kabuk olduğu söylenebilir, ancak farklı lisans ve GNU dışı proje statüsünün üstesinden gelmek için yeterli değil.

Linux dağıtımları ilk kez göründüklerinde ve varsayılan kabuklarını (90'ların ortalarından başlarında) seçerken, github (2008) ve hatta bir SourceForge (1999) bile yoktu. Bu noktada, GNU projelerinin fark edilmeden ve çizilmeden ve yeni geliştiriciler dahil edilmesinde GNU dışı projelere kıyasla gerçek bir avantajı olduğunu düşünüyorum. Bu yüzden dağıtımlar Z-kabuğuna daha iyi bakabilir, ancak Bash'in ileride iyi bir destek ve bakım alacağını ve ayrıca daha fazla özelliğe sahip olmasını bekler, böylece zsh'yi yakalar.

Artık Bash'in yıllarca varsayılan statüsü olduğu için, bunun hakkında yazılmış kitaplarla birlikte bir standart haline geldi. Orada bir kitap bu Bash ve Z-kabuk kapakları hem fakat Bash için bunu birden fazla varken, münhasıran kapakları bunu hiçbir kitap.

Ve bu noktada, dağıtımlar mevcut bir sistemin yükseltmeleri için varsayılanı değiştirecek olsaydı, başlangıç ​​dosyalarının bazıları farklı adlara sahip olduğundan (örn.. Bu nedenle, bunu yapmak için isteksiz olacaklardı, yeni indirmeleri varsayılan olarak zsh olacak şekilde bırakıp bash yapmak için yükseltmeleri bırakacaklardı. Aynı dağıtım için iki farklı varsayılan olasılık, muhtemelen desteklemek istemedikleri ve kullanıcılar / şirketler ile de uğraşmak istemedikleri bir şeydir.


1

Unix kabuk dillerinin hepsi çirkindir. Bazıları özellikle ( csh), bazıları belki biraz daha az ( ksh? Aslında bilmiyorum), ama gerçekten büyük projeler için okunabilirlik ve sertlik gibi hususlar söz konusu olduğunda, hiçbiri gibi iyi tasarlanmış genel amaçlı dillere yaklaşamıyor Python, C # veya Haskell. Bu nedenle, katı bir şey istediğinizde, hiçbir zaman kabuk tatlarından hiçbirini seçmeyeceksiniz.

Basit işleri hızlıca yapmak istediğinizde bunları seçersiniz. Bunun için ihtiyacınız olan:

  • Özlü sözdizimi ve yeterli tutarlılık, böylece gerçekten ezberleyebilirsiniz (stenografi operatörlerini aramak zordur). Eğer kabuğunuz her yere kurulursa çok önemlidir, çünkü bu çamur canavarlarından birden fazlasını ezberlemeyi tercih etmiyorsunuz.
  • İyi etkileşimli özellikler, doğrudan terminale girebilir ve birden fazla komut dosyası arasında geçiş yapmak zorunda kalmadan işlerinizi halledebilirsiniz.
  • Herhangi bir kod parçacığını herhangi bir yerden kapma ve yalnızca çalışmasını sağlama yeteneği. shuyumluluk burada büyük bir artı ve bir kez daha ne kadar popüler olursa o kadar iyi.

Görüyorsunuz, popülerlik bu kabuk dillerinde genel amaçlı dillerden daha büyük bir nokta. Bu nedenle ksh, başlı başına bir dil olarak “daha ​​iyi” olsa bile bash, sadece biraz daha popülerse (ilgili sektörde ilk kez varsayılan olarak seçildiğinden beri) onu kullanmakta pek bir avantaj yoktur. GNU için).

Geçiş yapan insanlar bu konuda bilinçlidir ve favori kabuklarına geçmeyi kolayca kaldıracak kadar deneyimlidirler. Daha az popüler bir kabukla çalışmak zorunda olan bir çaylak olan OTOH, İnternet'ten bir şey isteyip istemediklerini ve çalışmadıklarını çabucak karıştırıyor. Bu nedenle, yalnızca Unix gazilerine yönelik olmayan herhangi bir dağıtım bash, standarttan başka bir şey yaparsa , nispeten az insanın fayda sağlayabileceği bir adım (ve sadece biraz) bir miktar risk alır .


1
Boşluk miktarını önemseyen herhangi bir dil "iyi tasarlanmış" değildir, ancak popülerliğin anahtar olduğu konusunda hemfikirim.
Nagora,

1
@ Nagora: görüşler değişiyor. FWIW, Haskell'i her zaman beyaz boşluk yerine ayraç ve noktalı virgüllerle yazabilirsiniz. Sadece kimse bunu yapmaz çünkü girintili gruplama okunabilirlik açısından şaşırtıcıdır.
leftaroundabout

1
  1. İhtiyaç duyulduğunda oradaydı.
  2. Yeni başlayan kullanıcıların istediklerini kişiselleştirerek bir hafta geçirebilecekleri göz şekeri vardır.
  3. Yaygın kullanım durumları yeterince iyidir (en yaygın olanı tek bir komut başlatmaktır)
  4. Yeterince iyi olmadığı durumlarda perl, python ve lua gevşeyebilir.
  5. perl, korkunç bir etkileşimli kabuk yapar
  6. Her ne kadar balık, ksh veya zsh teorik olarak daha iyi bir kabuk olsa da, perl çok iyi çalıştığında veya taşınabilirliği bir sorun olduğu için rahatsız etmem için yeterli bir gelişme olmamasına rağmen, yine de çizgi çekmeyi hedefliyorum.

0

IMO, "Kritik Kütle" ana cevabı. Bash yalnızca komut satırı çalışması için değil, komut dosyası için de var ve orada çok büyük, çok sayıda Bash komut dosyası var. Şu anda etkileşim için bir alternatif ne kadar iyi olursa olsun, bu senaryoları yalnızca "tak ve çalıştır" yapabilme ihtiyacı bu avantajlardan daha ağır basmaktadır. Gibi, şimdi gerçekçi bir şekilde Bash'i yenebilecek tek kabuk tamamen geriye dönük uyumlu olan ve bunun için en muhtemel aday ... Bash'in bir sonraki sürümü.


1
Varsayılan kabuğunuzun ne olduğu farketmeksizin, tüm bash scriptlerini kullanabilirsiniz. She-bang'in (#! / Bin / bash) betiğin tepesinde anlamı budur.
Panter

1
@ bodhi.zazen Beşli kabuk sistemde olduğu sürece. En azından bash içermeyen bir Solaris sürümünü biliyorum.
Tulains Córdova

@ bodhi.zazen İki mermi arasında geçiş yapmanın zihinsel bir maliyeti var - biri etkileşim için, diğeri komut dosyası için. Genelde sıkıntıya değmez.
Nagora,

1
@ Nagora Bir senaryo çalıştırmanın zihinsel maliyeti nedir ?
kos

Eğer kelimenin tam anlamıyla sadece komut dosyalarını çalıştırıyorsanız, kos, hiçbiri. Senaryoları sürdürmek ve uyarlamak zorunda kalırsanız, farklı kabuklar arasında genellikle çok küçük farklar olduğunu aklınızda tutmanız gerekir; bu durumda, bazı işler yapmak istediğinizde devam eden bir metal maliyeti ve bağlam değiştirme maliyeti vardır. "diğer" sözdizimi.
Nagora
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.