shシンボリックにリンクすることのポイントは何dashですか？私はそれdashがより速いはずであることを理解していますがbash、オリジナルのshシェルがなぜ存在しないのかはわかりませんsh。
それとも、なぜshリンクされていないのbashですか？
shシンボリックにリンクすることのポイントは何dashですか？私はそれdashがより速いはずであることを理解していますがbash、オリジナルのshシェルがなぜ存在しないのかはわかりませんsh。
それとも、なぜshリンクされていないのbashですか？
回答:
「元のshシェルが存在しない理由」に対する簡単な答えは、元のshがないshことです。
わかりました、そこにあります：それはトンプソンシェルです。バージョン1には、今日知られているいくつかの機能、特にリダイレクトとパイプがありました（Unixの初期の歴史に関するDennis Ritchieの論文を読んでください）。それ以降のバージョンでは、バックグラウンドでの実行&、グロブ（外部プログラムで実装）、およびいくつかの形式の引用などの機能が追加されましたが、変数やネストされた制御構造はありませんでした。条件とループは、外部プログラムif（1つの条件と1つのコマンドを引数として使用）およびgoto（スクリプトファイル内の親のファイル位置を変更することで機能します）を介して提供されました。
1979年、Unix V7では、ThompsonシェルがBourneシェルに置き換えられまし/bin/shた。最初のリリースには、今日のダッシュに存在する多くの機能が既にあり、後続のバージョンにはさらに多くの機能が導入されています。数年後、Kornシェルが登場し、機能セットが増えました。多くのUnix亜種が名前でそれをインストールしました。ksh
1992年、POSIXshは基本的にBourneに加えていくつかの機能を備えた最小限の機能を成文化しました。「Unix」と呼ばれるシステムは、少なくともこれらの機能を実装する必要がありました。商用のUnixシステムは通常、POSIX shとしてkshを使用していましたが、いくつか（OSF / 1など）には独自のものがありました。
BourneシェルもKornシェルもごく最近までオープンソースではなかったため、1990年代半ばにLinuxの世界が形成され始めたとき、それらは利用できませんでした。/bin/sh別のものでなければなりませんでした。ほとんどのLinuxディストリビューションは、スクリプト機能の点でBourneとKornの間にある傾向があるGNUプロジェクトのシェルであるbashを使用し、インタラクティブな使用よりもはるかに優れています）。唯一の実行可能な代替では、無料のpdksh（「パブリック・ドメインKornシェル」）であった（現在は廃止され、しかしなどに住んでいるmkshされ、積極的に開発した）が、私はとしてpdkshのを使用しているLinuxディストリビューションを覚えていません/bin/shLinuxディストリビューションは常にGNU / Linuxディストリビューションであり、基本的にはGNUバージョンが存在するツールのGNUバージョンを出荷しているため、理由はわかりません。
sh「アッシュ」と呼ばれるオープンソースの実装もいくつかありましたが、最も顕著なのはAlmquistシェルでしたが、非常に不完全であり、使用したいPOSIX機能がいくつかありませんでした。DebianのメンテナーであるHerbert Xuであったプログラマーは、ashを拡張してPOSIX準拠にしました。最終的に彼のバージョンはダッシュに改名され/bin/sh、bashの代わりにDebianでそれを作成するためのプッシュが行われました。Ubuntuは、Debianが体系的にバシズム（#!/bin/shスクリプトでのbash固有の機能の使用）をバグとして扱うようになる前に始まりました。どちらも後で切り替えました（Ubuntu 6.10、Debianのみ2009年（それはlennyの目標でした しかし、切り替えはlennyのリリース後にのみ行われました。つまり、squeezeで）。
主要なダッシュとしてではなく、bashのを使用する理由として/bin/sh、それは非常に高速だということです。これはUbuntuにとって特に重要でした。Ubuntuは最初から起動時間を短くするよう努めてきました。また、dashはbashよりもメモリの使用量が少ない傾向があります。これは、基になるプログラムが終了したときに少しのクリーンアップを行うためだけに留まるラッパースクリプトにとっていくらか重要です。dashのもう1つの利点は、libc（コアシステムライブラリ）のみに依存しているのに対し、bashは端末サポートライブラリにも依存していることです（スクリプトなしでも起動できません）。これは、ダッシュが壊れたシステムで作業を続ける可能性が高いことを意味します。
21世紀のある時点で、Kornシェルがオープンソースになり、Bourneシェルのオープンソースバージョンが登場しました（開発は数年前に終了したため、古いバージョンです）。しかし、ダッシュとバッシュはLinuxの世界にしっかりと定着しており、特にBourneシェルは、今日の価値が歴史的なものであるため、受け入れられません。ダッシュは明確な利点を持っているため、バッシュを置き換えましたが、他の競合者のいずれもが決定的な利点を持っているわけではありません/bin/sh。
systemアプリケーションが行う（3）へのすべての呼び出しなど）でダッシュするのが支配的な要因です。
速度とPOSIX準拠（つまり、移植性）が主な要因です。/bin/shこれはシステムスクリプトを対象としていることを忘れないでください。これは、Ubuntuおよび/または他のシステムの古いバージョンに由来する場合とそうでない場合があります。
確かに、光沢のある機能はbashユーザーにとって使いやすいですが、いくつかの異なるサーバー/システムを管理しなければならない環境で物事を実行することになると、POSIX準拠のシェルを持つことは大きな違いをもたらします。特に、新しいシステム管理者であり、多くのスクリプトを使用する環境を継承している場合。
オリジナルのBourneシェルが存在しない理由については、単純です。AT＆T Bell Labsが元々所有していた独自の製品です。
また、Ubuntu wikiにはそれについて明確な説明があります。
なぜこの変更が行われたのですか？デフォルトのシェルを切り替える主な理由は、効率性です。bashは、インタラクティブな使用に適した優れたフル機能のシェルです。確かに、それはまだデフォルトのログインシェルです。ただし、ダッシュと比較すると、起動と操作がかなり大きく、遅くなります。Ubuntuブートプロセスの一部として、多数のシェルインスタンスが開始されます。/ bin / dashの下で明示的に実行するようにそれぞれを個別に変更するのではなく、大幅な継続的なメンテナンスが必要で、細心の注意を払わないと退行する可能性のある変更ではなく、Ubuntuコア開発チームは単に変更するのが最善であると感じましたデフォルトのシェル。Ubuntu 6.10での起動速度の向上は、多くの場合、Upstartに誤って起因していました。Upstartは、Ubuntu 6でのinitシステムの将来の開発用の優れたプラットフォームです。10は主にSystem V互換モードで実行され、動作にわずかな変更しかありませんでした。これらの改善は、実際には主に/ bin / shの変更によるものです。
そして、移植性に関する注意事項を次に示します。
Debianポリシーマニュアルでは、「 '/ bin / sh'をインタープリターとして指定するシェルスクリプトはPOSIX機能のみを使用する必要がある」と長い間義務付けられています。実際、この要件は、Ubuntuプロジェクトが開始されるかなり前から設定されています。さらに、BSDやSolarisなどの他のUnixシステムへの移植性が期待されるシェルスクリプトは、すでにこの要件を満たしていました。したがって、この変更による互換性への影響は最小限であると考えました。
dash必要とされない機能をサポートしていませんPOSIXか？
GNU / Linuxディストリビューションでは、「オリジナル/bin/sh」は実際にはBashです。
GNUはGPLの下にあるBourneのようなシェルを望んでいたので、GPL /bin/shライセンスではないBourneの代わりにBashを選択したのはそのためです。現代のLinuxディストリビューションはこの決定を継承し、/bin/shBashの事実上の標準になりました。オリジナルのBourneシェル（ "sh"）は、Solaris 10として最近になって他の非Linux Unixで使用されていますが、Linuxディストリビューションの主力ではありませんでした。
/bin/shbashからdashへの切り替えは、Debianの決定（Ubuntuに継承）であり、主に速度に動機付けられていました-起動速度の改善に多大な努力を注ぎ、実行中の一貫した時間で起動CPU時間の大部分初期化スクリプト。
Bashは引き続きユーザーのデフォルトの対話型/ログインシェルとして使用されますが、Dashは/bin/shinitスクリプトなどのシステムスクリプト用に実行されるものです。
Dashは非常に高速ですが、POSIXと非常に密接に互換性があります。これは、Bourneシェルと緊密に連携する標準です。ある意味では、BashからDashに切り替えることで、Bourneにより近いシェルに戻ります。
kshていますが、私は、POSIXである算術展開 `$（（））`を持つBourneシェルを思い出しません。
^パイプ文字です。したがって、POSIX shではecho foo ^ cat放出foo ^ catしfooますが、Bourne では放出します。この特定のテストは、Autoconfが2つを区別する方法です。
/bin/sh/bin/dash互換性の理由だと思うものにリンクされています。多くのスクリプトは単純に
#!/bin/shしたがってdash、シンボリックリンクに移動してシンボリックリンクを作成しないと、多くのスクリプトが/bin/shまったく存在しない場合、適切に（またはまったく）実行できません。
https://wiki.ubuntu.com/DashAsBinShによると、変更はbashto dashから行われました。
デフォルトのシェルを切り替える主な理由は、効率性です。bashは、インタラクティブな使用に適した優れたフル機能のシェルです。確かに、それはまだデフォルトのログインシェルです。ただし、ダッシュボードと比較すると、起動と操作がかなり大きく、遅くなります。Ubuntuブートプロセスの一部として、多数のシェルインスタンスが開始されます。/ bin / dashの下で明示的に実行するようにそれぞれを個別に変更するのではなく、大幅な継続的なメンテナンスが必要で、細心の注意を払わないと退行する可能性のある変更ではなく、Ubuntuコア開発チームは単に変更するのが最善であると感じましたデフォルトのシェル。
shリンクされていないbashので、
Debianポリシーマニュアルでは、「 '/ bin / sh'をインタープリターとして指定するシェルスクリプトはPOSIX機能のみを使用する必要がある」と長い間義務付けられています。
bashとして使用する場合/bin/sh：
問題がより広範囲に発生し、デフォルトのシステムシェルを元に戻す場合は、パッケージ管理システムに/ bin / shとしてのダッシュのインストールを停止するように指示できます。
sudo dpkg-reconfigure dash次のようにdash、bashが提供しない機能がいくつかあります。
bashが提供しないダッシュの機能に依存するスクリプトがいくつかあるという外部の可能性さえあります！
shをにインストールすると、/bin/shこれらのブートスクリプトが台無しになりますか？
/bin/shディストリビューションが提供するシェルは、ブートスクリプトなどでターゲットにしたものであるため、そのままにしておく必要があります。しかし、Bourneに置き換えた場合、ほとんど互換性があります。ただし、わずかな違いとコードの膨大な量が原因で、破損が発生することを想像します。もちろん、カスタムハッシュバングを使用して、独自のスクリプトでシェルを自由に使用できます。
/bin/shリンクするかは、特定のユーザーが最初のログインシェルとして設定したシェルとは別のものです。目標は、/bin/shユーザーが見ているに依存しない、とあなたが行う使用する必要がありsudo、-OR rootユーザーとして作用する他の手段-それを変更することを。また、一般的に、すべてのパッケージについて、dpkg-reconfigurerootとして実行する必要があります。対照的に、ユーザーは通常、自分の初期ログインシェルを変更することが許可されており、chshコマンドを使用して変更できます。最初のログインシェルの名前も入り、$SHELLいくつかのインタラクティブな非ログインシェルにも使用されます。