シェルがないオペレーティングシステムはどのように見えますか？

bashやcommand.com（Windows MEまで）やCMD.EXE（後のバージョン）などのシェルは、（特に）ユーザーからのコマンドを受け入れるインターフェイスを提供します。シェルが実行される前のオペレーティングシステムはどのように見えますか？最初のシェルが開発される前のシステムはどのように使用されていましたか（1970年代初期のUNIXなど）。コンピューターがコマンドを受け入れることさえできない場合（コマンドラインがない場合）、ユーザーはどのように操作できますか？この最も基本的なインターフェイスは何ですか？このインターフェイスをターミナルエミュレータで実行できますか、またはシェルの背後に行く方法はありませんか？

シェルが実行される前のオペレーティングシステムはどのように見えますか？

OSとその構成方法によって異なります。Linuxは、テキストモードコンソール、フレームバッファーコンソール、シリアルポートのいずれであっても、ブートテキストをコンソールデバイスに書き込むように構成できます。また、完全にサイレントになるように構成することもできます。一部のOS /システムは、システムを開発者モード、デバッグモード、または診断モードにすることでアクセスできる不揮発性メモリに診断情報を書き込む場合があります。多くのオペレーティングシステムは、何らかの形式のUARTへのブートおよび診断情報の出力をサポートします。これは、ユーザーから隠されていてもユニットで何らかの形で利用できる場合があります。あなたはそれらに到達することができます）。

OSには外部ディスプレイはまったく必要ありません。OSの単なる別のデバイスです。

最初のシェルが開発される前のシステムはどのように使用されていましたか（1970年代初期のUNIXなど）。

基本的に（そして多くを省きますが、これでアイデアが得られるはずです）-パネルのスイッチを切り替えるか、ペーパーテープリーダーを使用してプログラムをロードし（これらのデバイスはCPUの介入なしにメモリに直接書き込みます）、次に開始します別のスイッチを持つCPU。CPUはこのプログラムを実行し、その出力を生成して停止します。これは、対話式処理ではなくバッチ処理です。別のプログラムを実行したい場合は、これをやり直す必要がありました。

コンピューターがコマンドを受け入れることさえできない場合（コマンドラインがない場合）、ユーザーはどのように操作できますか？

私はこの分野の専門家ではありませんが、Altair、IMSAI、PDP-8などの古くて古いコンピューターには、CPUを直接制御し、CPUの介入なしでメモリを直接読み書きできるフロントパネルスイッチがありました。

この最も基本的なインターフェイスは何ですか？

最近のCPUのほとんどではないにしても、ほとんどの場合、同じタイプの直接操作を可能にする「JTAGポート」があります。長い間、ほとんどのコンピューターは、OSに渡す前に電源を入れたときにシステムを制御するROMまたはファームウェアを搭載することが期待されてきたことに留意してください。ここには、プリブートユーティリティが存在するか、そのようなユーティリティをロードするための最小限のメカニズムが存在します。U-Bootなどの一部のブートローダーは、シリアルポート経由でアクセスできます。ブートローダーはOSの「背後」で実行されるのではなく、OSをロードし、それに制御を渡し、その後は実行されなくなります。

このインターフェイスをターミナルエミュレータで実行できますか、またはシェルの背後に行く方法はありませんか？

いいえ、JTAGインターフェースが必要です。それはエレクトロニクスの領域に飛び込んでおり、GuruPlugが付属しており、GuruPlugのボード上のフラッシュチップを直接プログラムできることを除いて、私はそれについてあまり知らないことを認めます-何かがブートローダーを殺す場合GuruPlug、フラッシュバックする「CPUに依存しない」方法があります。

今日一般的に使用されている用語（ユーザーから対話的にコマンドを受け取るアプリケーションを意味する）として、オペレーティングシステムはシェルを提供する必要はありませんが、そのようなオペレーティングシステムは、ユーザー。Oliver Salzburgが述べているように、それはおそらく空白の画面を表示するだけです（ディスプレイ出力をサポートしている場合）。ブートおよびカーネル初期化プロセス中のLinuxカーネルの診断出力を例に取ります。

シェルは、グラフィカルシェル、コマンドラインインタープリターなど、オペレーティングシステムが提供する機能を使用して、コマンドの読み取り、プロセスの起動、I / Oリダイレクトなどを行います。

しかし、これらの施設を使用するアプリケーションがない理由がない持っていることをシェルが。

昔は、オペレーティングシステムは単に各アプリケーションがゼロから書き直さなければならない「有用なルーチン」の集まりであり、コンピューターは本質的にバッチ処理デバイスでした。ファイル、ディスク、プリンターI / Oのようなものは、おそらく現在オペレーティングシステムとして知られているものに最初に収集され、その後プロセススケジューリングが続きました（1960年代初期のApollo Guidance Computerはマルチタスクコンピューターであったことに注意してください））。その後、アプリケーションは、独自のルーチンを使用してそのようなことを行う代わりにOSを呼び出すことができ、プログラミングの複雑さを軽減し、おそらくコードサイズまたは実行時間を削減するのに役立ちます（これらのシステム機能は、誰もが恩恵を受けると、一度最適化およびデバッグできるため） 。コンピューターがますます一般的になるにつれて、オペレーティングシステムは、ユーザーがコンピューターと対話し、対話形式でコマンドを与える方法など、ユーザー中心の機能を追加しました。グラフィカルシェルは、その一連の推論の単なる拡張です。

また、それほど昔ではなく（1980年代後半まで）、通常のオペレーティングシステムの助けを借りずに、裸のパソコンハードウェアで実行するアプリケーションを記述することはまだかなり一般的でした。オペレーティングシステムのメモリと処理のオーバーヘッドを適切に回避するため、これはゲームに特に役立ちましたが、他の例もあると確信しています。これらの場合、ある程度まで、アプリケーションは独自のオペレーティングシステムであり、結果として、そのアプリケーションによって提供されるユーザーインターフェイスはシェルでした。

初期のコンピューターには、今日私たちが使用している意味でのOSがありませんでした。ハードウェアに実装された機能を、実行中のプログラムに直接公開しました。同時に実行されるプログラムは1つだけでした。プログラム自体がすべてのタスクを制御する必要があり、OSによって「バックグラウンドで」何も実行されませんでした。

しかし、それでもユーザーがプログラムを開始するためのエントリポイントがありました。言葉を広げると、これを「シェル」と呼ぶことができます。しかし、基本的には、実行するプログラムの最初のビットをユーザーが入力するのを待っているハードウェアだけです。押されたボタン、フリックされたスイッチ、スイッチボード上の接続されたワイヤ、パンチカード、パンチされたフィルムまたは磁気テープの形である。以前にロードされたいくつかのプログラムオプションから選択することもできたかもしれません。しかし、横にあるボタンを押して白熱灯として表示されたリストから選択することは、すでに「シェル」と見なすことができます。

したがって、「シェル」の定義が「ユーザーからのコマンドを受け入れるインターフェース」である場合、少なくともコンピューターをあいまいに呼ぶデバイスでさえ、それまでは時間がありませんでした。

入出力の観点にはあまり焦点を当てていませんが、コンピューティングの歴史についてのかなり良いウィキペディアのページをチェックしてください。

おそらく空白の画面になります。

シェルは、おそらくという名前のシェルを、カーネル（オペレーティングシステムであるカーネル）の周りのシェルですので。したがって、ある意味では、オペレーティングシステムのユーザーインターフェイスです。

オペレーティングシステムのみがコンピュータをシャットダウンすることであろう1つの機能を持っていた、とあなたが任意のキーボード入力を受け付けた後、その関数を呼び出すプログラムを構築したとすると、それはシェルです。ユーザーとのインターフェイスを構築するために複雑なコマンドラインインターフェイスを用意する必要はありません。

歴史的な観点から、パンチカード（https://en.wikipedia.org/wiki/Punched_card）があったと思います。コンピューターシステムと対話するため。しかし、これはあなたの質問のはるか昔に遡ると思います。

大学卒業後の最初のOS（1981年）は、PrimeミニコンピューターのPRIMOSでした。これはタイムシェアリングオペレーティングシステムであり、RS232ケーブルを介してコンピューターに接続された端末を使用する複数のユーザーをサポートしていました。ユーザー名とパスワードを入力して端末にログオンする必要がありました。ターミナルセッションは一種のシェルでした。ファイルを編集したり、コンパイルしたり、私たちが最近やっていることをすべて実行したりできます。すべての端末が同じファイリングシステムにアクセスできました。ほとんどの場合、これらの端末はタイプライターにすぎませんでした。WYSISWYGエディターも、emacsさえも夢ではありませんでした。

オペレーティングシステムは、現在とほぼ同じように構成されており、オニオンスキンのレイヤーとして想像できます。最も内側の層には、ハードウェア制御、メモリアクセスなどの非常に低レベルの機能がありました。外側に行くと、ファイルシステムが追加され、ユーザーレイヤーが追加されます。プログラムでは、いくつかのレイヤーを操作できますが、最も内側のレイヤーは操作できません（したがって、タイムシェアリングや実際のハードウェア（ライトなど）を台無しにすることはできません）。シェルのないコンピューターは、これらの内部レイヤーの1つに似ており、ハードディスクやテープリーダーにアクセスできるかもしれません（実際に！）が、ファイルやユーザーについては知りません。

初期のコンピューターを起動するには、基本的な一連の指示を読み込む必要がありました（これには、コンピューター上の一連の物理スイッチを切り替える必要があります）。このシーケンスにより、2つ目の小さなプログラムが開始され、テープリーダーが動作する可能性があります。次に、テープリーダーを介してより複雑なシステムをロードすると、ディスクドライブがオンラインになる可能性があります。シェルレスOSは、これらの初期ローダーの1つと考えることができます。

最近のコンピューターには同様のシーケンスがあるため、マシンを起動すると、ディスク、ネットワークカード、ビデオカードなどを起動するBIOSが読み込まれ、BIOSはハードディスク上の特定のプログラムを探して実行します（Windowsで）少なくとも）。Unixは、非常に基本的なモジュールからカーネルを徐々にセットアップし、ログインプロンプトが表示されるまでそれらを構築していくような、似たようなことを行います。

定義としてのオペレーティングシステムはかなりあいまいです。カーネル自体ですか？それはカーネルと付属ツールですか？Linuxはカーネルですが、GNU / LinuxはLinuxカーネルとGNUプロジェクトツールに基づいたオペレーティングシステムです。シェルは、このようなオペレーティングシステムの不可欠な部分です。

ただし、Linuxが起動して「ブート」が終了したら、実行するプログラムを指定する必要があります。それ以降、すべてが特定のプログラムの手に渡ります。デフォルトではinit、次に何をすべきかを知っており、最終的に素敵なGUIログイン画面が表示されます。しかし、そのようにする必要はありません。このように起動できます

kernel /boot/vmlinuz-2.6.30 root=/dev/sda1 ro init=/bin/fancy

その後、プログラム/bin/fancyは「Hello world！」を出力します。そのためにシェルは必要ありません。あなたには、いくつかの他のプログラムを起動したい場合だけで新しいプロセスを生成man 2 forkしてman 2 execve、または端末デバイスから読み込まれ、ユーザーの入力を受け付けます。まだシェルは必要ありません。

私の見解では、オペレーティングシステムシェルは、ユーザーの入力を読み取って、別のプログラムを起動できるプログラムです。考えてみれば、なぜこのようなプログラムを作成したいのかは明らかです。

ユーザーの入力をインタラクティブに読み取る必要がない場合でも、タスク用の単純なシェルスクリプトを記述する方がはるかに便利です。その場合、それは単に保存されたシェルコマンドのインタープリターです。他の言語のインタプリタでプログラムを書くこともできます。

コマンドラインシェルまたはグラフィカルインターフェイスのないオペレーティングシステムには、他の多くの種類の「フェイス」があります。

組み込みシステムは、車のエンジン管理システム（OBD2インターフェースと適切な端末を介して何らかの方法で取得できます）のような、ユーザーインターフェースなしで機能します。または、デジタルキーパッド、ノブなどを備えている場合があります（電子レンジ、エレベータ、または最新のサウンドシステムのフェースプレートなど）。もちろん、これらをシェルのフォームと見なすかどうかは主観的です。

ここに、趣味家として、シェルのない便利なコンピューターを作成する方法の高レベルのレシピがあります。

• マイクロコントローラ用の回路基板を構築するか、汎用基板を入手してください。
• それを接続して、たとえば水分センサーや水バルブなどのいくつかの有用なデバイスを駆動します。マイクロコントローラには、UART、GPIOなど、この目的のための周辺ピンがあります。
• ファームウェアを作成してセンサーを監視し、土壌に水をまきます。
• 開発ツールを使用してファームウェアをアップロードします（したがって、ホストコンピューターに何かを読み込んで実行するためのシェルは必要なく、ファームウェアはチップ上のフラッシュメモリに保存されます）。プログラミングには、マイクロコントローラを特別なプログラミングボードに接続する必要がある場合や、実際のボードに座っている間にそれを行う方法がある場合があります。ボードはPCに接続し（今日では、たとえばUSBを介して）、ホスト上のIDEやコマンドラインツールなどのツールを使用します。
• 物を展開する：これは本質的には電子ブラックボックスであり、何らかの方法で土壌水分を監視し、他の入力や出力なしで水をオンにします。

シェルのない非常に初期の汎用コンピューターには、パンチカードの読み取りなどの入力手段がありました。しかし、もちろん、パンチされたカードは区別する必要がありました。パンチされたカードはコンピューターに特別なコマンドを与えますか、それともFortranプログラムの一部ですか？そのため、事実上のコマンドラインである「ジョブ制御言語」を開発する必要がありました。

パンチカードとジョブ制御言語の前に、プログラマはマシンにバイナリコードを送るためにスイッチを切り替える必要がありました。ブートストラップを開始するために命令シーケンスを「切り替える」必要があった昔からの話を聞いたことがあるかもしれません。ジャンパーまたはDIPスイッチを備えたデバイスがまだ存在し、ファームウェアの設定と比較してこれらにはいくつかの利点があります。

私が立ち往生した最初のコンピューターは1977年のSiemens 305で、FORTRAN IVを学んでいました。コマンドを実行し、診断メッセージを紙に印刷するタイプライター、パンチカードリーダー、パンチテープリーダー/ライター、およびプリンターがありました。40 MBの取り外し可能なハードディスク、16インチ程度を忘れないでください。そのため、すでにシェルがあり、インターフェイスはタイプライターでした。

1970年代のコマンドシェルに相当するものとして、デバッガーとテキストエディター（DDTとemacs）を実行したことを覚えています。そのため、eshellを介してプログラムを実行するデバッガーに対して実行される他のプログラムで、コンソールモードでemacsを実行すると、密接な経験が得られます。

emacsには完全なLisp環境があるため、優れたコマンド履歴編集と複数の仮想端末に加えて、非常に優れたマクロとスクリプト機能が組み込まれていることに注意してください。