質問編集履歴
9
修正
test
CHANGED
File without changes
|
test
CHANGED
@@ -74,7 +74,7 @@
|
|
74
74
|
https://qiita.com/angel_p_57/items/1faafa275525469788b4
|
75
75
|
https://qiita.com/angel_p_57/items/03582181e9f7a69f8168#%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E3%81%A8%E7%94%BB%E9%9D%A2%E3%81%A3%E3%81%A6
|
76
76
|
|
77
|
-
**☑シェルへの
|
77
|
+
**☑シェル、デバイスファイルへの理解**
|
78
78
|
シェルは画面ではない。対応する動作をカーネルに指示する実態は目に見えないもの。
|
79
79
|
この事実をしっかり理解していればスムーズに理解が及んでいたように思える。
|
80
80
|
|
8
追記
test
CHANGED
File without changes
|
test
CHANGED
@@ -67,3 +67,28 @@
|
|
67
67
|
ご指摘や修正など賜れましたら幸甚でございます。
|
68
68
|
よろしくお願いいたします。<(_ _)>
|
69
69
|
|
70
|
+
以下追記のみ....
|
71
|
+
|
72
|
+
参考になりました。
|
73
|
+
この2記事でほぼ自分の疑問や間違いなど訂正されました。
|
74
|
+
https://qiita.com/angel_p_57/items/1faafa275525469788b4
|
75
|
+
https://qiita.com/angel_p_57/items/03582181e9f7a69f8168#%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E3%81%A8%E7%94%BB%E9%9D%A2%E3%81%A3%E3%81%A6
|
76
|
+
|
77
|
+
**☑シェルへの最終的な理解**
|
78
|
+
シェルは画面ではない。対応する動作をカーネルに指示する実態は目に見えないもの。
|
79
|
+
この事実をしっかり理解していればスムーズに理解が及んでいたように思える。
|
80
|
+
|
81
|
+
シェル自身では入力や出力を用意できないから、それをosの仮想コンソールドライバが用意
|
82
|
+
している。
|
83
|
+
このドライバが画面であり、入力も受け持つ。
|
84
|
+
|
85
|
+
コンソールは初期として複数用意されている。
|
86
|
+
その際に、各osの仮想コンソールドライバとコンソールを紐づける管理情報としてデバイスファイル
|
87
|
+
があり、中身は単にその管理情報があるのみ。
|
88
|
+
|
89
|
+
仮想コンソールドライバ1 <=> /dev/tty1
|
90
|
+
仮想コンソールドライバ2 <=> /dev/tty2 ...
|
91
|
+
この時、当然いくつこのセットができようと各セットが紐づくシェルは一つ。
|
92
|
+
|
93
|
+
たったこれだけの基礎を頭に入れるだけで、他のことが応用として理解がすぐに及んだ。
|
94
|
+
|
7
変更
test
CHANGED
File without changes
|
test
CHANGED
@@ -11,6 +11,7 @@
|
|
11
11
|
・各プロセス
|
12
12
|
などもファイルに該当する。
|
13
13
|
|
14
|
+
(追記)本文は、WSL1環境でのものであり、純粋に起動したLinux環境のGUI端末ではデバイスファイルは、/dev/pts/1... のようになる。
|
14
15
|
|
15
16
|
|
16
17
|
**・デバイスファイル(スペシャルファイル)について**
|
@@ -20,6 +21,7 @@
|
|
20
21
|
|
21
22
|
上のデバイスファイルはいつ作られるのかと言うと、Bashシェルが起動した際、その起動したものに1:1で特定できるように作成され、
|
22
23
|
/dev/以下にtty1, tty2...のように配置される。
|
24
|
+
(修正)正確には起動前に作られる。
|
23
25
|
これのおかげで複数のBashを立ち上げてもそれぞれのターミナルでそれぞれの標準入・出力が行われ、被ることはない。
|
24
26
|
|
25
27
|
意図的に echo 'aaa' > /dev/tty1(他のターミナルのデバイスファイル)という風にして標準出力先を変更(リダイレクト)させることは可能
|
@@ -32,18 +34,24 @@
|
|
32
34
|
|
33
35
|
**・プロセスについて**
|
34
36
|
上の文でもプロセスは非常に関係している。
|
35
|
-
linuxにおいては全て(コマンド、ファイル実行...)はプロセス
|
37
|
+
linuxにおいては全て(コマンド、ファイル実行...)はプロセス単位毎に管理される。
|
38
|
+
psコマンドで確認可能
|
36
39
|
|
37
40
|
プロセスには親プロセスと子プロセスというものがあり、大元最上位に来る親がubuntuではinit(=systemd)
|
38
|
-
なので、bashを立ち上げるとそのタイミングではinit__bashという形となっている。
|
41
|
+
なので、bashを立ち上げるとそのタイミングではinit...__bashという形となっている。
|
42
|
+
(追記)init...としているのは、実際にはsystemdとbashの間にはまだ多くのプロセスが介在しているから。
|
39
43
|
そして、bashで起動したコマンドなどはそのbashプロセスの子プロセスとなる。
|
40
44
|
|
41
45
|
全てのプロセスがどれかのbash(デバイスファイル=tty)に紐づいているという訳ではなく、
|
42
46
|
例えばsystemdは必要なものや作成してenableしたサービスのプロセスを立ち上げるているので、この段階でも他にいくつかのttyに紐づかないプロセスが立ち上がっている。
|
43
47
|
|
44
48
|
pythonプログラムもプロセスとして起動するので、仮にそのプログラム内でsubprocess.Popen('ls')としていた場合、
|
45
|
-
init__bash__python__[ls] という形となる。
|
49
|
+
init...__bash__python__[ls] という形となる。
|
50
|
+
|
46
|
-
当然別のbashで同じプログラムを起動した場合はそのbashのプロセスが親となり、その子プロセスとしてpythonプログラムが動く。(両者initという共通の親プロセス)
|
51
|
+
当然、別のbashで同じプログラムを起動した場合はそのbashのプロセスが親となり、その子プロセスとしてpythonプログラムが動く。(両者initという共通の親プロセス)
|
52
|
+
|
53
|
+
(追記)なぜ、あるシェルで実行したコマンドの出力がそのシェルの標準出力と同じところ(画面)に出るかというと、親プロセスのfdの状態を子プロセスは受け継ぐため。
|
54
|
+
つまり、親の標準出力(入力、エラー、その他3以上のも同様)などのfdと同じファイル(やデバイスファイル)を向く。
|
47
55
|
|
48
56
|
|
49
57
|
**・デバイスファイルとプロセスとfdと標準入出力、標準エラー出力の関係について**
|
6
追加
test
CHANGED
File without changes
|
test
CHANGED
@@ -6,7 +6,11 @@
|
|
6
6
|
|
7
7
|
Linuxでは全てをファイルとして扱うという仕様があり、それを理解することが
|
8
8
|
Linuxを深く理解する上で重要なこと。
|
9
|
-
ファイルはかなりフワフワとした概念で、
|
9
|
+
ファイルはかなりフワフワとした概念で、
|
10
|
+
・デバイスファイルという特殊ファイル
|
11
|
+
・各プロセス
|
12
|
+
などもファイルに該当する。
|
13
|
+
|
10
14
|
|
11
15
|
|
12
16
|
**・デバイスファイル(スペシャルファイル)について**
|
5
tty/1 => tty1
test
CHANGED
File without changes
|
test
CHANGED
@@ -15,10 +15,10 @@
|
|
15
15
|
なので、Bashシェルなどで入力と出力が抽象化された形で行える。
|
16
16
|
|
17
17
|
上のデバイスファイルはいつ作られるのかと言うと、Bashシェルが起動した際、その起動したものに1:1で特定できるように作成され、
|
18
|
-
/dev/tty
|
18
|
+
/dev/以下にtty1, tty2...のように配置される。
|
19
19
|
これのおかげで複数のBashを立ち上げてもそれぞれのターミナルでそれぞれの標準入・出力が行われ、被ることはない。
|
20
20
|
|
21
|
-
意図的に echo 'aaa' > /dev/tty
|
21
|
+
意図的に echo 'aaa' > /dev/tty1(他のターミナルのデバイスファイル)という風にして標準出力先を変更(リダイレクト)させることは可能
|
22
22
|
これは、echo 'aaa' > my.txt としているのと原理的に何ら変わりはない。(SSH接続時も同様)
|
23
23
|
つまり、ファイルさえ手元にあれば(sshの場合は許可が当然必要)どこで起動しているターミナルであれ、そこのファイル(デバイスファイル)に
|
24
24
|
リダイレクトさせることができる。
|
4
markdown
test
CHANGED
File without changes
|
test
CHANGED
@@ -4,13 +4,12 @@
|
|
4
4
|
|
5
5
|
---
|
6
6
|
|
7
|
-
|
8
7
|
Linuxでは全てをファイルとして扱うという仕様があり、それを理解することが
|
9
8
|
Linuxを深く理解する上で重要なこと。
|
10
9
|
ファイルはかなりフワフワとした概念で、デバイスファイルという特殊ファイルも該当する。
|
11
10
|
|
12
11
|
|
13
|
-
・デバイスファイル(スペシャルファイル)について
|
12
|
+
**・デバイスファイル(スペシャルファイル)について**
|
14
13
|
デバイスファイルというのは、仮想的(ソフトウェア)に入力と出力を実現させる機構を備えたプラットフォームのようなもので、
|
15
14
|
キーボードを標準入力、ターミナル画面を標準出力という構造の中身を気にしなくていいようにしてくれている。
|
16
15
|
なので、Bashシェルなどで入力と出力が抽象化された形で行える。
|
@@ -27,7 +26,7 @@
|
|
27
26
|
某サイト様ではデバイスファイルのことを画面ファイルと表現されており、これは個人としてはしっくりきた。
|
28
27
|
|
29
28
|
|
30
|
-
・プロセスについて
|
29
|
+
**・プロセスについて**
|
31
30
|
上の文でもプロセスは非常に関係している。
|
32
31
|
linuxにおいては全て(コマンド、ファイル実行...)はプロセスが起動し、プロセス毎に管理される。psコマンドで確認可能
|
33
32
|
|
@@ -43,7 +42,7 @@
|
|
43
42
|
当然別のbashで同じプログラムを起動した場合はそのbashのプロセスが親となり、その子プロセスとしてpythonプログラムが動く。(両者initという共通の親プロセス)
|
44
43
|
|
45
44
|
|
46
|
-
・デバイスファイルとプロセスとfdと標準入出力、標準エラー出力の関係について
|
45
|
+
**・デバイスファイルとプロセスとfdと標準入出力、標準エラー出力の関係について**
|
47
46
|
全てのプロセスには、必ずfd:0, fd:1, fd2が自動でセットされる。
|
48
47
|
当然、個々のbashプロセスにも、lsコマンドにも、pythonスクリプトにも...
|
49
48
|
なので、bashプロセスでlsと打つことができる(標準入力)し、もし仮にlsが何らかの入力を求めるものだったとしたら、そのlsプロセスにも標準入力することができるし、
|
3
修正
test
CHANGED
File without changes
|
test
CHANGED
@@ -33,9 +33,12 @@
|
|
33
33
|
|
34
34
|
プロセスには親プロセスと子プロセスというものがあり、大元最上位に来る親がubuntuではinit(=systemd)
|
35
35
|
なので、bashを立ち上げるとそのタイミングではinit__bashという形となっている。
|
36
|
-
|
36
|
+
そして、bashで起動したコマンドなどはそのbashプロセスの子プロセスとなる。
|
37
37
|
|
38
|
+
全てのプロセスがどれかのbash(デバイスファイル=tty)に紐づいているという訳ではなく、
|
39
|
+
例えばsystemdは必要なものや作成してenableしたサービスのプロセスを立ち上げるているので、この段階でも他にいくつかのttyに紐づかないプロセスが立ち上がっている。
|
40
|
+
|
38
|
-
|
41
|
+
pythonプログラムもプロセスとして起動するので、仮にそのプログラム内でsubprocess.Popen('ls')としていた場合、
|
39
42
|
init__bash__python__[ls] という形となる。
|
40
43
|
当然別のbashで同じプログラムを起動した場合はそのbashのプロセスが親となり、その子プロセスとしてpythonプログラムが動く。(両者initという共通の親プロセス)
|
41
44
|
|
2
修正
test
CHANGED
File without changes
|
test
CHANGED
@@ -16,7 +16,7 @@
|
|
16
16
|
なので、Bashシェルなどで入力と出力が抽象化された形で行える。
|
17
17
|
|
18
18
|
上のデバイスファイルはいつ作られるのかと言うと、Bashシェルが起動した際、その起動したものに1:1で特定できるように作成され、
|
19
|
-
/dev/ 以下に配置される。
|
19
|
+
/dev/tty/ 以下に配置される。
|
20
20
|
これのおかげで複数のBashを立ち上げてもそれぞれのターミナルでそれぞれの標準入・出力が行われ、被ることはない。
|
21
21
|
|
22
22
|
意図的に echo 'aaa' > /dev/tty/1(他のターミナルのデバイスファイル)という風にして標準出力先を変更(リダイレクト)させることは可能
|
1
追加
test
CHANGED
File without changes
|
test
CHANGED
@@ -4,33 +4,52 @@
|
|
4
4
|
|
5
5
|
---
|
6
6
|
|
7
|
-
linuxでは全てファイルとして扱う。(それにはデバイスファイルという特殊ファイルも含む)
|
8
|
-
デバイスファイルは立ち上げるシェル毎にそれぞれ割り当てられる。
|
9
|
-
/dev/tty/1, /dev/tty/2....のように
|
10
7
|
|
8
|
+
Linuxでは全てをファイルとして扱うという仕様があり、それを理解することが
|
11
|
-
|
9
|
+
Linuxを深く理解する上で重要なこと。
|
12
|
-
前提として最初にinit == systemdのプロセスが起動し、それ以降はそのプロセスの子プロセスとなる形で起動する。
|
13
|
-
例えば、bashというシェルを起動するとinit__bashという感じになる。
|
14
|
-
そして、bashで立ち上げるプロセス(各種コマンドやpythonプログラム)は、bashの子プロセスとして起動する。
|
15
|
-
例えば、pythonプログラム内でsubprocess.open('ls')を書いたものを実行すると
|
16
|
-
init__bash__python__[ls] という感じになる。(pythonプロセスやその中のlsプロセスは使用後は削除される。)
|
17
|
-
|
18
|
-
ファイルデ
|
10
|
+
ファイルはかなりフワフワとした概念で、デバイスファイルという特殊ファイルも該当する。
|
19
|
-
必ず割り当てらえる。
|
20
|
-
そして、その割り当てられるものが、ターミナル毎に振られる個々のデバイスファイル(/dev/tty/1..)
|
21
|
-
bashというプロセスにも同様に割り当てられているので、コマンドをキーボード入力(=標準入力)できる(lsとか)。
|
22
|
-
起動した何等かのコマンドもプロセスなので当然fd(0,1,2)が割り当てられる。
|
23
|
-
なので、標準入力を求められる時にキーボードでYesとかできるし、その応答がターミナル(display)=デバイスファイルに帰って来る。
|
24
|
-
|
25
|
-
echo 'aaa' > my.txt とすれば標準出力の先をデバイスファイルから変更(リダイレクト)できるが、
|
26
|
-
例えばシェル1(/dev/tty/0) , 2(/dev/tty/1)と立ち上げて、1から2へ
|
27
|
-
echo 'aaa' > /dev/tty/1 としても上と同じ原理でリダイレクトする(ssh接続も同じこと)。
|
28
|
-
|
29
|
-
某サイト様にはデバイスファイルのことを画面ファイルと表現していた部分があり、これは個人的にしっくりくる表現だった。(標準入力の部分が少し曖昧になるけれど...)
|
30
11
|
|
31
12
|
|
13
|
+
・デバイスファイル(スペシャルファイル)について
|
14
|
+
デバイスファイルというのは、仮想的(ソフトウェア)に入力と出力を実現させる機構を備えたプラットフォームのようなもので、
|
15
|
+
キーボードを標準入力、ターミナル画面を標準出力という構造の中身を気にしなくていいようにしてくれている。
|
16
|
+
なので、Bashシェルなどで入力と出力が抽象化された形で行える。
|
17
|
+
|
18
|
+
上のデバイスファイルはいつ作られるのかと言うと、Bashシェルが起動した際、その起動したものに1:1で特定できるように作成され、
|
19
|
+
/dev/ 以下に配置される。
|
20
|
+
これのおかげで複数のBashを立ち上げてもそれぞれのターミナルでそれぞれの標準入・出力が行われ、被ることはない。
|
21
|
+
|
22
|
+
意図的に echo 'aaa' > /dev/tty/1(他のターミナルのデバイスファイル)という風にして標準出力先を変更(リダイレクト)させることは可能
|
23
|
+
これは、echo 'aaa' > my.txt としているのと原理的に何ら変わりはない。(SSH接続時も同様)
|
24
|
+
つまり、ファイルさえ手元にあれば(sshの場合は許可が当然必要)どこで起動しているターミナルであれ、そこのファイル(デバイスファイル)に
|
25
|
+
リダイレクトさせることができる。
|
26
|
+
|
27
|
+
某サイト様ではデバイスファイルのことを画面ファイルと表現されており、これは個人としてはしっくりきた。
|
28
|
+
|
29
|
+
|
30
|
+
・プロセスについて
|
31
|
+
上の文でもプロセスは非常に関係している。
|
32
|
+
linuxにおいては全て(コマンド、ファイル実行...)はプロセスが起動し、プロセス毎に管理される。psコマンドで確認可能
|
33
|
+
|
34
|
+
プロセスには親プロセスと子プロセスというものがあり、大元最上位に来る親がubuntuではinit(=systemd)
|
35
|
+
なので、bashを立ち上げるとそのタイミングではinit__bashという形となっている。
|
36
|
+
systemdは必要なものや作成してenableしたサービスのプロセスを立ち上げるているのでこの段階でも他にいくつかのttyに紐づかないプロセスが立ち上がっている。
|
37
|
+
|
38
|
+
例えば、pythonプログラムもプロセスとして起動するので、仮にそのプログラム内でsubprocess.Popen('ls')としていた場合、
|
39
|
+
init__bash__python__[ls] という形となる。
|
40
|
+
当然別のbashで同じプログラムを起動した場合はそのbashのプロセスが親となり、その子プロセスとしてpythonプログラムが動く。(両者initという共通の親プロセス)
|
41
|
+
|
42
|
+
|
43
|
+
・デバイスファイルとプロセスとfdと標準入出力、標準エラー出力の関係について
|
44
|
+
全てのプロセスには、必ずfd:0, fd:1, fd2が自動でセットされる。
|
45
|
+
当然、個々のbashプロセスにも、lsコマンドにも、pythonスクリプトにも...
|
46
|
+
なので、bashプロセスでlsと打つことができる(標準入力)し、もし仮にlsが何らかの入力を求めるものだったとしたら、そのlsプロセスにも標準入力することができるし、
|
47
|
+
その結果が画面ファイル(デバイスファイル)へと表示される(標準出力)。
|
48
|
+
|
32
49
|
---
|
33
|
-
まだまだ確認したい点がございますが、一番重要な部分かと考えておりますのでこのあたりに間違いや修正が必要ではないか知っておきたいと存じます。
|
34
50
|
|
51
|
+
大体このような認識でeverything_is_file という概念を大まかに理解したつもりではいるのですが、
|
52
|
+
抽象化された概念や解説が多く、全く自信がございません。
|
53
|
+
ご指摘や修正など賜れましたら幸甚でございます。
|
35
54
|
よろしくお願いいたします。<(_ _)>
|
36
55
|
|