web-dev-qa-db-ja.com

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

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

私は両方を使用しますが、私のすべてのタスクは単純です:)

38
Talal

私はこれを読んで、結論は GNU (ほとんどのLinuxベースのOSで使用される)のデフォルトのシェルであるため、単にGNUの一部としてパッケージ化されているようです。 20年の開発の背後にあり、安定性と丸みを帯びた、最高のオールラウンドであり、最も高度なユーザーを除くすべてのニーズを満たしています。

詳細については、 なぜLinuxでbashが標準なのですか? (UnixとLinuxでも同じ質問です)をお読みください。

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

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

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

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

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

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

33
Mark Kirby

UnixのAT&TブランチのBourne Shell(sh)は、Korn Shellによって改良され、置き換えられましたksh。 kshもAT&T Bell Labsから出てきたもので、GPLではありませんでした(現在のバージョンはEclipse Public Licenseです)。 C-Shellcshはバークレー版のUnixから出てきたもので、GPL(BSDライセンス)でもなく、shとは異なる構文を使用していました。 Z-Shellzshは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-Shellをより良く見ることができますが、Bashが今後も優れたサポートとメンテナンスを取得し、さらに多くの機能が追加され、zshに追いつくことを期待できます。

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

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

9
Scooter

Unixシェル言語はすべて見苦しいです。特に(csh)、いくつかは少し少ない(ksh?実際にはわからない)が、実際には大きなプロジェクトの読みやすさや硬さなどの面に関しては、どれも取得できないPython、C#、Haskellなどの適切に設計された汎用言語に近い。したがって、しっかりしたものが必要な場合は、シェルフレーバーをまったく選択しません。

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

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

ご覧のとおり、これらのシェル言語では、汎用言語よりも人気がかなり重要です。したがって、ksh自体が言語として少し「優れている」としても、bashが少しだけ人気がある場合(関連する分野では)それはGNUのデフォルトとして最初に選択されたためです。

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

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

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

0
Nagora