シェルというプログラム(プロセス)が行っている大まかなことの理解

Question

普段、コマンドプロンプトにコマンドを入力してbashなどのシェルに仲介してもらっていますが、
あまり中のことを気にしていませんでした。

大まかにでいいので、理解があっているか、確認できればと思います。

例えば、とあるシェルがCで書かれているとすると、

char cmd[256];

while(True){
    
    scanf("%s", cmd); // ここでプロセスはスリープ(コマンド入力待ち) 
    switch (&cmd){

    case "echo":
    // fork() からの execev("/bin/echo.exe", ...);

    case "cd":
    // 組み込みコマンドをここで実行

    case "./ + カレントディレクトリのプログラム":
    // fork() からの execev("./ANY.exe", ...);

    default:
    printf("そんなコマンド知りません。\n");
    }

}

・主に上のようなループ体制でユーザからの注文をカーネルが分かるものに"変換"している。
・当然シェル自体(プログラム)はメモリにロードされているので、そのバイナリがCPUによって実行さている。
・ウェブ上で調べると、変換などと何やら特殊なことをしているようだが、変換といっても単にあるコマンドが来たら、そのコマンドに対応する処理にswitchなどで分岐させているだけのこと。
・勝手に独自のシェルを作って使用されないように、OSの一部としてシェルを配布し、その渡したシェル以外からは一切カーネルへの注文を受け付けないように構築しておくことで、安全性を確保している。
・デーモンプロセスだろうと普通のプロセスだろうと、プロセスを生成する際には、必ず一度はシェルの子プロセスとして作られる。(シェルを通さずにプロセスを実行する手段、ルートはユーザには設けられていない。)

大体このような認識となっております。
何か認識のミス等ありましたら、ご教授ください。

Comments

[hoshi-takanori]

シェルも普通のプログラムの一種に過ぎず、特別なことはしてません。(というか、シェルにできることは他のプログラムにもできますし、もちろん自分で新しいシェルを作ることもできます。)
シェルと他のプログラムとの違いは、シェルの一番の仕事は他のプログラムを実行すること、ってくらいでしょうか。

[akiyama_pga]

ありがとうございます。
>シェルにできることは他のプログラムにもできます
確かに、なぜか自分はシェルにしかできないことがあり、シェルを使わなくてはいけないという暗黙の了解が自分の中にできてしましっていました。
単にラッパー関数のように、渡された引数により、多くの面倒なコードを引き受けているだけだと...

自作シェルということが可能のようですので、勉強も兼ねて作成してみたいと思います。

Answer 1

・主に上のようなループ体制でユーザからの注文をカーネルが分かるものに"変換"している。

正確には、ユーザーの注文を理解して、それをもとにカーネルにシステムコールを出したりしています。

・ウェブ上で調べると、変換などと何やら特殊なことをしているようだが、変換といっても単にあるコマンドが来たら、そのコマンドに対応する処理にswitchなどで分岐させているだけのこと。

変数展開のことを指しているのかもしれません。
その他にも、コマンド置換(コマンドの出力を引数に渡す)などがあります。

・勝手に独自のシェルを作って使用されないように、OSの一部としてシェルを配布し、その渡したシェル以外からは一切カーネルへの注文を受け付けないように構築しておくことで、安全性を確保している。

そんなことはしていません。cshやzshなどをインストールすることは普通にできます。

$ sudo apt update
$ sudo apt install csh
$ csh

そもそも、カーネルモジュールがインストールできたりするのに、わざわざシェル以外の注文を受け付けないようにする意味がありません。

・デーモンプロセスだろうと普通のプロセスだろうと、プロセスを生成する際には、必ず一度はシェルの子プロセスとして作られる。(シェルを通さずにプロセスを実行する手段、ルートはユーザには設けられていない。)

linuxを触っていないので詳しくは分かりませんが、シェルは、init processであるsystemd が呼び出すloginというプログラムが、または、ターミナルエミュレーターが呼び出していたと思います。
カーネルがsystemdを、また、systemdがloginを呼び出す時に、わざわざシェルを通したりしません。

Comments

[akiyama_pga]

ご回答ありがとうございます。
最後の部分で理解が進みました。

CUIログインでは、ユーザのセッションにログインシェルとして常にシェルがあり、ユーザは通常そのシェルを用いてプログラムを起動したりするため、いつの間にかシェルを通さなければプログラムは実行できないと勘違いをしていました。

おっしゃります通り、bashの前身となるloginプロセスはカーネルが臨時的に実行する起動プログラムから実行されており、その際にはまさにシェルは介していないと思います。
つまり、シェルは絶対的な門ではない、ということが分かります。

シェルスクリプトでは、最初に使用するシェルを指定します。
その時点でシェルは単なるラッパーであり、基本的な解析・分岐の機能を持つものであれば何であれ正しく動作することができると思います。
(ただ、ログインシェルが流れ的に親になっているだけのことで)

誰でも独自にシェルは作成できるし、
シェルにしかできない機能は(ほぼ)ないと理解できました。

[akiyama_pga]

本日、シェルの変更という作業を行ってみました。

sudo apt install tcsh
tcsh
>ls

この単純な作業でよくわかりました。
bash(login shell) -- tcsh -- ls
このlsはbashの組み込みlsではなく、tcshの組み込みlsである。
この図のtcshの部分を担うプログラムを自力で書けば、それは独自シェルということになると思います。

今では、なぜ自分はシェルがos配布のものしか使えないと決めつけていたのか、全く理解できません。

[68user]

> このlsはbashの組み込みlsではなく、tcshの組み込みlsである。

組み込みの ls を持つシェルってありましたっけ。少なくとも bash も tcsh も /bin/ls なり /usr/bin/ls を実行しているだけではないかと思います。

Answer 2

・当然シェル自体(プログラム)はメモリにロードされているので、そのバイナリがCPUによって実行さている。

はい。

・主に上のようなループ体制でユーザからの注文をカーネルが分かるものに"変換"している。
・ウェブ上で調べると、変換などと何やら特殊なことをしているようだが、変換といっても単にあるコマンドが来たら、そのコマンドに対応する処理にswitchなどで分岐させているだけのこと。

「変換」の意味が不明。
全体がループで、行入力して、解析して分岐して実行という、荒いレベルでは合ってます。
シェルがコマンドラインをどういう風に処理するのかは、bashだとman bashを読めば書いてあります。
他のシェルでも同様に、man に書いてあるはず。
(man zshに比べると）man bash は短いので通読してみましょう。日本語版がインストールされてなければ、https://linuxjm.osdn.jp/html/GNU_bash/man1/bash.1.html で。（行編集「READLINE ライブラリ」の所は飛ばして良いです）

・勝手に独自のシェルを作って使用されないように、OSの一部としてシェルを配布し、その渡したシェル以外からは一切カーネルへの注文を受け付けないように構築しておくことで、安全性を確保している。

これは、全くの間違い。
独自のシェルを使うのは全然問題ないし、それを禁止しようなどと誰も考えたことも無いでしょう。
Windowsですら、explorer.exeは差し替え可能です（少なくとも以前は）。

・デーモンプロセスだろうと普通のプロセスだろうと、プロセスを生成する際には、必ず一度はシェルの子プロセスとして作られる。(シェルを通さずにプロセスを実行する手段、ルートはユーザには設けられていない。)

これも間違いですね。
OSから見ると、シェルは単なるアプリケーションプログラムです。

Comments

[akiyama_pga]

毎度お世話になっております。
シェルの大して大きな誤解があったようです...
別にシェルが無くても使用上は問題ないが、無ければ、
・制御端末のグループ管理が大変、
・面倒な起動プログラムを一々自作する大きな手間がかかる、
・長いプログラムを短いコマンドで短縮できない、
、のような苦労が付きまといますよ、程度のものでしょうか。

よく考えますと、上で自分で書いたプログラムを走らせてそれに適当な名前を付ければ、張りぼてではあるがシェルという機能を一部は満たしたものではないかと、気づきました。
ご提示頂きました資料を通読した上で、一度しっかりとしたシェルを作成してみたいと思います。

変換ではなく、"解釈"と書くべきでございました..

[otn]

> 別にシェルが無くても使用上は問題ないが、無ければ、
「シェルが無い」というのはどういう状態のことですかね？
人間が操作するコンピューターであれば必ずシェルはあります。人間の操作を受け取る物がシェル。
WindowsのExplorerも（広義の？）シェルですよ。

> 上で自分で書いたプログラムを走らせてそれに適当な名前を付ければ、張りぼてではあるがシェルという機能を一部は満たしたものではないかと、気づきました。

過去に、自分でシェルを作りながら、出てきた疑問を数回質問している人がいました。
あるいは、大学の演習で作ったりしてるところもあるのでは？

[akiyama_pga]

おっしゃります通り、エクスプローラーもシェルだという認識をもっております。
何らかの合図を渡すと、カーネルに対して代わりに要求を出してくれるプログラムで、その合図は文字であってもクリックであってもそれを解析する処理があるならば問題ないと思います。

シェルが無い、という状況で何らかのプログラムを動かすことはユーザ側からは不可能であり、
そのような状況は予め決まったものを決まったタイミングで実行する用途で、カーネル側でのみ成立する概念かと思います。
(人間はいつ、どのような操作を要求するか不定のため、やはりシェルは必要)
この点は誤記ですみません。

自分の思い違いは、ユーザはlinux起動後、ログインシェル(その子となる形でしか)を通じてしか、プログラムを実行できないので、
シェルを通じてしかプログラムを実行できないと思ってしまった点にありまして、
本質的にあるプロセスを実行するには、それを実行するプログラムが必要であり(fork(), execev()する土台)それがユーザには初期としてログインシェルであるbash等になるだけの話であって、
bash(login shell)->独自shell-> ./プログラム であってもいいと思いますし、
独自shell(login shell) -> ./プログラム であってもいいと思います。

単純なことを何か難しく考えてしまっていました...
余