ほとんどのOSでbashがデフォルトのシェルであるのはなぜですか？

ほとんどのOS（Ubuntu、Fedora、OSXなど）でbashがデフォルトのシェルになっているのはなぜですか？多くの上級ユーザーが主にzshを使用するのはなぜですか？それが良い場合、なぜデフォルトではないのですか？

私は両方を使用しますが、すべてのタスクは単純ですので違いはありません:)

私はこれについていくつか読んで、結論はGNUのデフォルトシェル（ほとんどのLinuxベースのOSで使用されている）であり、したがってGNUの一部としてパッケージ化されているだけでなく、20年の開発を経て安定した、丸みのある、最高のオールラウンダーであり、最も高度なユーザーを除くすべてのニーズを満たします。

詳しくは、Linuxでbashが標準となっている理由をご覧ください。（UnixとLinuxでも同じ質問です）。

これにもう少し追加するために、試してみる他のシェルがたくさんあります。興味があるなら、この答えからいくつかを紹介します：

• Zshにはより高度なインタラクティブ機能がありますが、スクリプティングに関してはいくつかの癖があります（以前ほどではありません）。Linuxが初期段階にあった1990年代初期から中期にかけて、zshは事実上不明でした。

• Kshは、1980年代半ば以降の商用ユニセのデファクトスタンダードでしたが、2000年まではプロプライエタリソフトウェアであったため、Linuxではオプションではありませんでした。また、bshと比較して、kshにはコマンドライン編集機能がありません。

• kshの無料クローンであるPdkshはオプションでしたが、あまり知られておらず、コマンドラインエディションの機能が貧弱でした。（Pdkshは、一部のBSDでまだ使用されていますが、ATT kshが無料になったため、あまりアクティブなプロジェクトではなくなりました。）

• 一部のディストリビューションは、灰のバリアントをとしてインストール し /bin/shます。Ash（つまり、ashと呼ばれる緩やかなシェルファミリのいずれか）は、インタラクティブ機能を持たず、小さくて高速になるように設計されています（スクリプトの編集専用です）。灰の復活は比較的最近です。1990年代には、既存のバリアントには多くの機能が欠けていました。

• Tcshは、zshが登場するまで最も高度なインタラクティブシェルでしたが、shと互換性がなく、スクリプト作成にはあまり適していません。

UNIXのAT＆TブランチのBourne Shell（当時はshでした）は、Korn Shell kshによって改良され、置き換えられました。また、kshはAT＆T Bell Labsから出たもので、GPLではありません（現在のバージョンはEclipse Public Licenseです）。Cシェルであるcshは、バークレー版のUnixから生まれたもので、GPL（BSDライセンス）でもなく、shとは異なる構文を使用していました。Zシェルであるzshはshを改良したものですが、GPL（MITのようなライセンス）ではありません。Bashはshの改良であり、GPLを使用し、GNUから提供されました。ライセンスだけで、BashはおそらくGPLオペレーティングシステムの選択肢でした。特に、シェルがディストリビューションのコア部分である場合。

しかし、BashはGNUプロジェクトでもあったため、Berkeley UnixやAT＆T Unixのレガシー製品よりも、より積極的な開発と貢献を容易にしていると思います。zshがBashよりも優れたシェルであるという非常に良いケースを作ることができますが、異なるライセンスと非GNUプロジェクトのステータスを克服するには十分ではありません。

Linuxディストリビューションが最初に表示され、デフォルトのシェル（90年代半ばまで）を選択したとき、github（2008）もSourceForge（1999）もありませんでした。その時点で、GNUプロジェクトは、GNU以外のプロジェクトに比べて、注目を集めて新しい開発者を取り込むという点で本当に有利だったと思います。そのため、ディストリビューションはZシェルをより良く見ることができますが、Bashが今後も優れたサポートとメンテナンスを取得し、さらに多くの機能が追加され、zshに追いつくことを期待できます。

Bashには何年もデフォルト状態があったので、それについて書かれた本で、それは事実上の標準になりました。BashとZ-shellの両方をカバーする本が1つありますが、それだけをカバーする本はありませんが、Bashについては複数の本があります。

この時点で、既存のシステムのアップグレードのデフォルトをディストリビューションが変更すると、一部の初期化ファイルの名前が異なるため（たとえば.bashrcと.zshrc）、ファイルの内容に互換性のない構文が含まれるため、セットアップが中断します。したがって、彼らはそうすることを非常に嫌がり、新しいダウンロードはデフォルトとしてzshを持ち、アップグレードはbashを持ちます。同じディストリビューションの2つの異なるデフォルトは、おそらくサポートする必要はありませんし、ユーザー/企業も同様に対処する必要はありません。

Unixシェル言語はすべて見苦しいです。特に（csh）、少し少なめかもしれません（ksh？ Python、C＃またはHaskell。したがって、しっかりしたものが必要なときは、シェルフレーバーをまったく選択しません。

簡単なことをすぐにやりたいときに選択します。これには、次のものが必要です。

• 簡潔な構文と十分な一貫性により、実際に暗記することができます（速記演算子を探すのは困難です）。シェルがどこにでもインストールされている場合、それは非常に重要です。なぜなら、これらのクラッジモンスターのうちの2つ以上を本当に記憶する必要はないからです。
• 優れたインタラクティブ機能。端末に直接ハックして、複数のスクリプトファイルを切り替えることなく作業を開始できます。
• スクリプトスニペットをどこからでも取得して、機能させることができます。sh互換性はここで大きなプラスであり、もう一度人気が高いほど良いです。

したがって、これらのシェル言語では、汎用言語の場合よりも人気の方がかなり重要です。したがってksh、それ自体が言語として少し「優れている」としても、それがbash少し人気がある場合（それがデフォルトとして最初に選択されたので、関連するセクターであった場合）、それを使用することはそれほどそれほど有利ではありませんGNU用）。

切り替えを行う人は、それについて慎重であり、お気に入りのシェルへの切り替えを簡単に処理できる十分な経験があります。あまり人気のないシェルで作業することを余儀なくされた新人であるOTOHは、インターネットに何かを求めて、それが機能しない場合、すぐに混乱します。したがって、Unixの退役軍人を対象としたディストリビューションはbash、標準以外の比較的少数の（そしてほんの少しの）利益をもたらすステップである場合、かなりのリスクを伴います。

1. 必要なときにそこにいた
2. 初心者のユーザーがプロンプトをカスタマイズするのに1週間費やすことができるほど十分な見た目があります。
3. 一般的な使用例で十分です（最も一般的なのは、単一のコマンドを開始することです）
4. perlが十分ではない場合、pythonとluaは余裕を取ります。
5. perlはひどいインタラクティブなシェルを作ります
6. fish、ksh、またはzshは理論的にはより良いシェルかもしれませんが、perlがうまく機能するか、移植性が問題になるので気にするほどの改善は十分ではありません。

「クリティカルマス」が主な答え、IMOです。Bashはコマンドラインの作業だけでなく、スクリプト作成のためのものであり、膨大な数のBashスクリプトが世に出ています。インタラクションの代替手段がどれほど優れていても、これらのスクリプトを「プラグアンドプレイ」できる必要性は、そのような利点よりも重要です。そのため、Bashを現実的に外すことができる唯一のシェルは、完全に後方互換性があり、そのための最も有力な候補は... Bashの次のバージョンです。