sh trap wait
WATANABE Katsuhiro
しらい たかし <shi...@nintendo.co.jp> さんが
記事 <9e39lu$3h3$1...@nsvn01.zaq.ne.jp> でいはく
> そして、ここからが重要な話なんですが、job 制御には端末制御
> の問題がつきまといます。foreground job と background とで端
> 末入出力を分け合う訳です。
> 例えば cat(1) を引数無しで実行すると、stdin を食って stdout
> を吐くという繰返しをしますが、これを「cat &」として background
> で実行させると SIGTTIN を受けて停止します。つまり background
> process は端末を持たないことが判ります。
違います。最後の文が直前の文からどうして導出できるのか不明です。
background process(以下 bg proc.) も 間違いなく制御端末を持って
いるでしょう。例えば以下のようなお馴染みの徴候を挙げておきます：
1. ps(1) で bg process を見ると、TT(制御端末)が結びついています。
2. ユーザが(bg proc. の制御)端末から logout した時などは、
bg proc. に SIGHUP が送られてきます。
3. bg proc. から出力を試みても、通常は SIGTTOU で停止しません。
(しらいさんの説明法が留保条件なく正しいのなら、そのまま 3.に
適用して「端末を持つことが判ります。」が導出可となります。)
bg proc. が端末から read(2) を試みたときに SIGTTIN を受けるのは、
端末を持たないからではなく、端末側から process を調べてみると
foreground process (group)になっていないからでしょう。
Takashi SHIRAI
In article <uy9bbe...@katsu.watanabe.name>,
WATANABE Katsuhiro <ka...@watanabe.name> wrote:
>あまりの follow-up の遅さが議論の妨げになっていたらごめんなさい。
遅いのは構わないのですが、そのためにそこいらの news server
では軒並 expire されていて文脈が追えないので、その辺りの配慮
をしてくれたら良かったんじゃないかと思います。
自分で書いた記事とは言え、何カ月も経ってしまったら完全に記
憶から消し去られてしまいますし。
>> 例えば cat(1) を引数無しで実行すると、stdin を食って stdout
>> を吐くという繰返しをしますが、これを「cat &」として background
>> で実行させると SIGTTIN を受けて停止します。つまり background
>> process は端末を持たないことが判ります。
>
>違います。最後の文が直前の文からどうして導出できるのか不明です。
多分 TIOCSPGRP の話を書きたかったんじゃないかと思います。
この手の話を正確性を欠かずに表現しようとすると非常に複雑な話
になるので、その辺りの詳細をぼかして判り易い表現で説明した結
果、厳密には事実と異なる表現になってしまっただけなんじゃない
でしょうか。
どういう文脈で出て来た話なのか全く思い出せないので、これ以
上は何とも判断し兼ねますが。
>background process(以下 bg proc.) も 間違いなく制御端末を持って
>いるでしょう。例えば以下のようなお馴染みの徴候を挙げておきます：
>1. ps(1) で bg process を見ると、TT(制御端末)が結びついています。
それは何をして「制御端末」と呼ぶかでしょう。ps(1) の TT の
値は kernel の process 管理構造体の中から、その process と結
びつけられた端末の名前を引用しているだけで、その process と
端末の関係までは関知しません。
一方、TIOCGPGRP により取得出来る process は一端末につき最
大一個であり、それ以外の process は端末の入出力を使うことは
出来ません。
元記事の文脈では、そういう制御可能な端末を持っているか否か
を言っているんだと思います。
＃ この辺り、POSIX 以前と以後とで微妙に表現が異なるかも知れ
＃ません。因みに「process」も正確には「process group」です。
>2. ユーザが(bg proc. の制御)端末から logout した時などは、
> bg proc. に SIGHUP が送られてきます。
それは完全に shell のお仕事です。kernel の仕事ではありませ
ん。background process に SIGHUP が送られるかどうかは shell
の実装に依存します。
因みに Bourne shell の実装では、shell が process 制御を行
なわない (fg も bg も非実装) ので、「&」で起動された process
は logout 後も生き続けます。
>3. bg proc. から出力を試みても、通常は SIGTTOU で停止しません。
これも shell の実装依存の筈です。単純に fork(2) と exec(2)
で shell を実装して、setpgrp(2) して親に TIOCSPGRP すると、
子は SIGTTOU で停止しますよ。
if (!(pid = fork())) {
setpgid(0, getpid());
execl("/bin/echo", "echo", "foo", NULL);
}
else if (pid > 0) {
tcsetpgrp(0, getpid());
waitpid(pid, &i, WUNTRACED);
if (WIFSTOPPED(i)) printf("%d\n", WSTOPSIG(i));
}
＃ 但し、tty driver の実装によっては local mode LTOSTOP の
＃状態に依存します。
>bg proc. が端末から read(2) を試みたときに SIGTTIN を受けるのは、
>端末を持たないからではなく、端末側から process を調べてみると
>foreground process (group)になっていないからでしょう。
その「端末に対する foreground process」という用法は POSIX
で出て来た termios 用語だと思いますよ。
--
しらい たかし
WATANABE Katsuhiro
アーカイブスポットはどこなのでしょう？TV CMでおなじみのとか、
アメリカで大流行のとか、モデル・女優も愛用のとかだと
嬉しいのですが。Queen はサービスが終了する予定だし、Google
だと漢字の表示が怪しいことがあるように見えます。
記事 <ajimpj$mbo$1...@nsvn01.zaq.ne.jp> で
しらい たかし <shi...@nintendo.co.jp> さんいはく
> >あまりの follow-up の遅さが議論の妨げになっていたらごめんなさい。
>
> 遅いのは構わないのですが、そのためにそこいらの news server
> では軒並 expire されていて文脈が追えないので、その辺りの配慮
> をしてくれたら良かったんじゃないかと思います。
> 自分で書いた記事とは言え、何カ月も経ってしまったら完全に記
> 憶から消し去られてしまいますし。
ごもっともです。
議論の本題は、wait が絡んだときの trap の振舞いがシェルによって
異なる理由を探ろうという点でした。この点については順調に話が
進んで結論が得られたようです。私は background process が
制御端末を持つかどうかという点だけに言及したく、これは UNIX
一般の話で元の文脈とは独立と思い、適当な部分の引用に留めました。
スレッドを構成する一連の記事は、現在はまだ以下の場所で参照
できるかと思います：
http://queen.heart.ne.jp/cgi-bin/browse?msgid=%3C9e2890%242cm%241%40sc6%2Eosa%2Esharp%2Eco%2Ejp%3E
http://queen.heart.ne.jp/cgi-bin/browse?msgid=%3C9e39lu%243h3%241%40nsvn01%2Ezaq%2Ene%2Ejp%3E
http://queen.heart.ne.jp/cgi-bin/browse?msgid=%3C9e9ti9%24323%241%40poinsettia%2Etrust%2Eco%2Ejp%3E
http://queen.heart.ne.jp/cgi-bin/browse?msgid=%3C9ehrgf%245it%241%40sc6%2Eosa%2Esharp%2Eco%2Ejp%3E
http://queen.heart.ne.jp/cgi-bin/browse?msgid=%3Csnm1ypfz5md%2Efsf%40indra%2Espp%2Ehpc%2Efujitsu%2Eco%2Ejp%3E
http://queen.heart.ne.jp/cgi-bin/browse?msgid=%3Csnmzoc3xpw6%2Efsf%40indra%2Espp%2Ehpc%2Efujitsu%2Eco%2Ejp%3E
http://queen.heart.ne.jp/cgi-bin/browse?msgid=%3C9f2ln7%24edd%241%40sc6%2Eosa%2Esharp%2Eco%2Ejp%3E
http://queen.heart.ne.jp/cgi-bin/browse?msgid=%3Csnmvgmiosin%2Efsf_%2D_%40indra%2Espp%2Ehpc%2Efujitsu%2Eco%2Ejp%3E
http://queen.heart.ne.jp/cgi-bin/browse?msgid=%3Csnmu222ornz%2Efsf%40indra%2Espp%2Ehpc%2Efujitsu%2Eco%2Ejp%3E
http://queen.heart.ne.jp/cgi-bin/browse?msgid=%3C9f8f8r%24bnh%241%40pin3%2Etky%2Eplala%2Eor%2Ejp%3E
じきなくなりそうなので、お早めにどうぞ。
--
渡邊克宏 http://katsu.watanabe.name
WATANABE Katsuhiro
という件についてです。
記事 <ajimpj$mbo$1...@nsvn01.zaq.ne.jp> で
しらい たかし <shi...@nintendo.co.jp> さんいはく
> >background process(以下 bg proc.) も 間違いなく制御端末を持って
> >いるでしょう。例えば以下のようなお馴染みの徴候を挙げておきます：
> >1. ps(1) で bg process を見ると、TT(制御端末)が結びついています。
>
> それは何をして「制御端末」と呼ぶかでしょう。
必ず /dev/tty が制御端末への通り道となっています。これは UNIX に
分類される OS すべてで共通です。(see [Linux][BSD][Solaris])
そして background process も /dev/tty にアクセスできます。
> ps(1) の TT の
> 値は kernel の process 管理構造体の中から、その process と結
> びつけられた端末の名前を引用しているだけで、その process と
> 端末の関係までは関知しません。
> 一方、TIOCGPGRP により取得出来る process は一端末につき最
> 大一個であり、それ以外の process は端末の入出力を使うことは
> 出来ません。
「最大一個」が出てくるあたりに、しらいさんの混乱を感じます。
「その proces と結びつけられた端末」が、通例 control terminal,
controlling terminal、制御端末と呼ばれているものです。そして、
端末からみた「TIOCGPGRP により取得できる process(group)」、
言い換えて controlling group に属してる process だけが
制御端末を持つと考えているのなら、それは誤りです。
process から見て制御端末は(存在すれば)一意に決まり /dev/tty
として提供されますね。ところが逆に、ある端末 t からみれば、t を
制御端末にしている process (group) は複数ありえます(全くない
こともある)。しらいさんの言う「最大一個」のわけがありません。
1対多の関係を何かの勘違いで1対1に押し込めてしまっているのでは。
私の主張を別な面から再びまとめます：
process に制御端末があれば、それは /dev/tty を通じて参照できる。
この関係は、その process が(シェルにより)background に
まわされたからといって変化するものではない。background の
process でも制御端末(すなわち有効な /dev/tty)を持つものはある。
controlling group に属する process だけが入出力できるというのも
事実と異なります。入力については 4BSD と SVR4 以降になって確かに
制限されるようになりましたが、それ以外の process が端末に出力を
することは普通にあります。(see [Job])
> それ以外の process は端末の入出力を使うことは
> 出来ません。
> 元記事の文脈では、そういう制御可能な端末を持っているか否か
> を言っているんだと思います。
念のため確認しておくと、制御端末(control terminal)という言葉は、
プロセスから見て「制御可能」な端末(制御の客体)のことをいって
いるのではなく、プロセス群を制御する主体を指していっています。
参考文献
[Job] Job Control on BSDi and SunOS systems;
http://www-acs.ucsd.edu/instructional/unix/jobctrlbsd.html;
"Both foreground and background jobs can write to the
controlling terminal."
[Linux] /dev/tty のような端末スペシャルファイル;
http://www.linux.or.jp/JF/JFdocs/Text-Terminal-HOWTO-6.html;
[BSD] mount_fdesc(8) on NetBSD;
http://www.tac.eu.org/cgi-bin/man-cgi?mount_fdesc+8+NetBSD-current など;
[Solaris] tty(7D) on Solaris;
http://docs.sun.com/?p=/doc/816-0222/6m6nmlt3g&a=view
[TermiosGen] Job Control や The Controlling Terminal の説明の節;
各種 OS の termios(4);
http://www.freebsd.org/cgi/man.cgi?query=termios&apropos=0&sektion=4&manpath=FreeBSD+4.6-RELEASE&format=html など;
[TermiosSol] Solaris のSession Management の説明の節;
http://docs.sun.com/?q=termios&p=/doc/816-0222/6m6nmlt36&a=view;
"Background process groups in the controlling process's
session are subject to a job control line discipline when
they attempt to access their controlling terminal."
[PS] ps(1) man page;
--
渡邊克宏 http://katsu.watanabe.name
Takashi SHIRAI
In article <u4rdqy...@katsu.watanabe.name>,
WATANABE Katsuhiro <ka...@watanabe.name> wrote:
>> それは何をして「制御端末」と呼ぶかでしょう。
>
>必ず /dev/tty が制御端末への通り道となっています。これは UNIX に
>分類される OS すべてで共通です。(see [Linux][BSD][Solaris])
>そして background process も /dev/tty にアクセスできます。
何だか話が噛み合ってませんね。渡邊さんの文章も私の文章も、
「制御端末」の定義によって真にもなるし偽にもなるという代物な
ので、文章そのものの真偽ではなくてまずは「制御端末」の定義を
先に明確にすべきだと言っているんです。
色々な文献を当たってみると、「control terminal」「controlled
terminal」「controlling terminal」と様々な原語を「制御端末」
という同じ訳で表している場面が見つかります。
「control」はともかく「controlling」と「controlled」とでは
意味が全然違いますよね。
で、その上で、私の原文の指す「制御端末」は TIOCSPGRP のこ
とを言ってるんだろうと、過去を思い出しつつ憶測した訳です。一
年以上も前の話で、その時何をどう考えていたかまではいちいち憶
えていられませんから憶測の域を出ません。
>> 一方、TIOCGPGRP により取得出来る process は一端末につき最
>> 大一個であり、それ以外の process は端末の入出力を使うことは
>> 出来ません。
>
>「最大一個」が出てくるあたりに、しらいさんの混乱を感じます。
>「その proces と結びつけられた端末」が、通例 control terminal,
>controlling terminal、制御端末と呼ばれているものです。そして、
>端末からみた「TIOCGPGRP により取得できる process(group)」、
>言い換えて controlling group に属してる process だけが
>制御端末を持つと考えているのなら、それは誤りです。
問題が「制御端末」の定義にあると思ったので、ここでは敢えて
「制御端末」という言葉を避けて記述しています。それをわざわざ
読み替えて話を引っかき回さないで下さい。
「制御」も「端末」も割と一般的な単語で、UNIX kernel の tty
を指す以外にも、FA 用のコンソールだとかリモートコントローラ
だとか、「制御 {する|用の} 端末」という一般的な概念を持って
います。
ですから、ここではいわゆる「controlling terminal」としての
意味以外に「制御端末」という呼称を用いてしまったことのみに焦
点をあてて、問題点を整理しようとした訳です。
ここでは渡邊さんは何をしたいのでしょうか？話を混ぜっ返した
いだけ？相手を言い負かしたいだけ？
＃ そもそも <uy9bbe...@katsu.watanabe.name> で何が言い
＃たいのか私には見えませんでした。
＃ 「一般に制御端末とは controlling terminal のことを指し、
＃setsid(2) 等で明示的に切り離さない限りは全ての process は
＃この制御端末を失わない」という指摘であれば「表現が不正確で
＃したね」済んだでしょうが、いきなり「違います」と来てその理
＃由として挙げられているものが意味不明だったもので。
＃ その辺りの事情は実装依存だし POSIX 前後で異なるし、表現
＃に曖昧さが残るのは否めないと思いますが、そういう話ではなく
＃て「background process が controlling terminal を持つ傍証」
＃として筋違いな根拠を持ち出されたのでは話が見えません。
>process から見て制御端末は(存在すれば)一意に決まり /dev/tty
>として提供されますね。ところが逆に、ある端末 t からみれば、t を
>制御端末にしている process (group) は複数ありえます(全くない
>こともある)。しらいさんの言う「最大一個」のわけがありません。
>1対多の関係を何かの勘違いで1対1に押し込めてしまっているのでは。
誰も「制御端末は最大一個」なんて言ってませんよ。人の話をね
じ曲げて自分に有利なように話を進めようとしていませんか？私が
敢えて「制御端末」という呼称を避けた苦労が水の泡です。
「TIOCGPGRP により取得出来る process」は「最大一個」で合っ
てますよね。私の表現は、元記事の「制御端末」はそのことが言い
たかったのだろうと言っているに過ぎなくて、「制御端末」が何な
のかを議論している訳ではありません。
>process に制御端末があれば、それは /dev/tty を通じて参照できる。
>この関係は、その process が(シェルにより)background に
>まわされたからといって変化するものではない。background の
>process でも制御端末(すなわち有効な /dev/tty)を持つものはある。
で、それは元の議論にどう結び付くんでしょうか？この一節は単
に「controlling terminal に関する一般論」を述べただけの話で、
trap & wait の挙動とは関係ないでしょう。
つまり、文章としては合っているけれども文脈としては合ってい
ない一節であり、本題から見たらどうでもいい話に過ぎません。
元記事の表現は「制御端末」の指し示すものが何であるかという
点に疑問が残るというだけで、文脈的には本題に沿った話を展開し
ていますよね。
だから問題なのは何をして「制御端末」と呼ぶか、この一点のみ
なんじゃありませんか、というのが私の問いかけだった訳です。問
題の本質を見失って下らない揚げ足取りに終始させないで下さい。
＃ とは言え、この文脈でいきなり TIOCSPGRP の話を持ち出すの
＃も唐突過ぎるかも知れない。何を導きたくてこんな話にしたんだ
＃ろう？何せ一年以上も前のことなので皆目見当がつかん．．．。
＃ Date: 見ると金曜深夜なので、酒かっくらっていい気分になっ
＃てただけだったりして :-)
--
しらい たかし
WATANABE Katsuhiro
以下のような私の反省でもって勘弁してやってください。
記事 <ajtgig$6i7$1...@nsvn01.zaq.ne.jp> で
しらい たかし <shi...@nintendo.co.jp> さんいはく
> ここでは渡邊さんは何をしたいのでしょうか？話を混ぜっ返した
> いだけ？相手を言い負かしたいだけ？
本題の trap & wait の話から派生独立させて、
「background process も制御端末を持つことがある」
という主張を展開したかったのです。さらにそれに皆さんが合意して
もらえれば嬉しいと思いました。mohta さんは「(議論は)勝ち負けですよ」
と言っていますが、私は違います。古い話を発掘して蒸し直すのが大好き
なのは認めますが、混ぜっ返す意図はありません。
> 私の表現は、元記事の「制御端末」はそのことが言い
> たかったのだろうと言っているに過ぎなくて、「制御端末」が何な
> のかを議論している訳ではありません。
しらいさんとは逆に、私の意図は、専ら「制御端末」が何なのかと
その特質だけを論じることでした。
> >process でも制御端末(すなわち有効な /dev/tty)を持つものはある。
> この一節は単
> に「controlling terminal に関する一般論」を述べただけの話で、
> trap & wait の挙動とは関係ないでしょう。
まさに私の投稿企図どおりです。trap & wait と全く無関係に、
controlling terminal に関する一般論に焦点を当てようとしたのが
私の投稿です。
> つまり、文章としては合っているけれども文脈としては合ってい
> ない一節であり、本題から見たらどうでもいい話に過ぎません。
私はその、本題でない・本来の文脈ではない部分こそを、皆さんと
議論したかったのです。
反省するに、すれ違いの原因のひとつは、
渡邊の記事 <u4rdq6...@katsu.watanabe.name> の
> 議論の本題は、wait が絡んだときの trap の振舞いがシェルによって
> 異なる理由を探ろうという点でした。この点については順調に話が
> 進んで結論が得られたようです。私は background process が
> 制御端末を持つかどうかという点だけに言及したく、
という私のお断りが事後になってしまった点ではないでしょうか。
おわびします。誤解を生まないよう Subject: も変更すべきでした。
--
渡邊克宏 http://katsu.watanabe.name
Tanaka Akira
WATANABE Katsuhiro <ka...@watanabe.name> writes:
> 「background process も制御端末を持つことがある」
常に持つ気がします。
SUSv3 によれば、
background process group
(Or background job.) Any process group, other than a foreground process
group, that is a member of a session that has established a connection with
a controlling terminal.
というように、background process group は定義により制御端末を持つもの
のうち foreground process group でないものを指すので、制御端末を持たな
いものは background process group とは呼ばないのではないのでしょうか。
それとも SUSv3 とは異なる定義ないし慣習があるということでしょうか。
--
[田中 哲][たなか あきら][Tanaka Akira]
「ふえろ! わかめちゃん作戦です⊇」(Little Worker, 桂遊生丸)
Takashi SHIRAI
In article <hvo4rdnr4...@coulee.a02.aist.go.jp>,
Tanaka Akira <a...@m17n.org> wrote:
> (Or background job.) Any process group, other than a foreground process
> group, that is a member of a session that has established a connection with
> a controlling terminal.
>
>というように、background process group は定義により制御端末を持つもの
>のうち foreground process group でないものを指すので、制御端末を持たな
>いものは background process group とは呼ばないのではないのでしょうか。
ん？事実関係はともかくとして、その英文はこう訳すのが正しい
ような気がするんですが。
「フォアグラウンドプロセスグループ以外の全てのプロセ
スグループ。フォアグラウンドプロセスグループとは、制
御端末に関連づけられたセッションのメンバのこと。」
「that」が「,」を二つも跨いだ先を修飾していると捉えると、
「,」で区切られた部分が修飾的にしか働かないように扱われます
が、この文の主題はむしろその「,」で区切られた部分では？
多分「connection」も「持つ」ではなくて TIOCSPGRP 的な関連
づけを指しているんだと思います。
＃ それとも TIOCNOTTY された daemon 類は「background process
＃group」と呼んじゃいけないのかしらん？
--
しらい たかし
Takashi SHIRAI
In article <uptwby...@katsu.watanabe.name>,
WATANABE Katsuhiro <ka...@watanabe.name> wrote:
>> 私の表現は、元記事の「制御端末」はそのことが言い
>> たかったのだろうと言っているに過ぎなくて、「制御端末」が何な
>> のかを議論している訳ではありません。
>
>しらいさんとは逆に、私の意図は、専ら「制御端末」が何なのかと
>その特質だけを論じることでした。
そういうことであれば、私が「それは何をして『制御端末』と呼
ぶかでしょう」と回答した時点で、「私はこれこれを『制御端末』
と呼んでいます。そしてその意味に於いて制御端末とは．．．」と
続ければ良かったんじゃないでしょうか。
私はあの元記事ではそういう意味で「制御端末」を用いていなか
ったと思われるので、違う意味の単語について自説を展開されたと
ころで、言っている内容は正しくとも会話が成立しないと思いませ
んか？
例えば、「車には運転免許が要る」に対して「違います。車は自
転車や乳母車にもついていますが、それらの乗物は運転免許を必要
としません」と反論しているようなものです。
前者の「車」が「自動車」の意味で用いられているのに対し、後
者は「車輪」の意味で用いているという点だけが争点であって、前
者の発言は別に「自転車や乳母車運転免許が要る」と主張している
訳ではありませんよね。
何を議論したいのかが明らかになれば、その後「車輪と運転免許
の関係」などという無意味な議論には発展しない筈ですが、論点を
見失うとそういう無意味な議論になってしまいます。
多分、あの元記事では「端末制御」という単語に引きずられて、
「shell が制御する端末」という意味で「制御端末」と言ってしま
ったんじゃないかと思うんです。
所謂「controlling terminal」のことを指している訳ではありま
せんから、渡邊さんの反論は全く噛み合っていなかったことになり
ます。
渡邊さんはその論点に気づかずに自分の言いたいことだけを主張
し続けたので、私にとっては全然議論になっていなかったのでした。
＃ 因みにこの「端末制御」も意味が曖昧ですね。shell の仕事と
＃しての文脈では ioctl() 的な制御を指しますが、termios 的な
＃制御も「端末制御」と呼ぶことがありますから。勿論この文脈で
＃は前者です。
>まさに私の投稿企図どおりです。trap & wait と全く無関係に、
>controlling terminal に関する一般論に焦点を当てようとしたのが
>私の投稿です。
それならば「はいそうですね」でおしまいです。
＃ 別に私がそういう一般知識を持っていない訳じゃありませんし。
＃用語や用法はともかく、その手の知識が無いと shell の開発な
＃んか出来ませんからね。
>私はその、本題でない・本来の文脈ではない部分こそを、皆さんと
>議論したかったのです。
で、signal と端末との関係に言及する場合には、「controlling
terminal」よりは「TIOCSPGRP された端末」の方がより密接な関係
にあることは理解して頂けたでしょうか？
＃ ひょっとしたら、端末が直接 background process に SIGHUP
＃を送るような UNIX の実装もあるのかも知れませんけど、その場
＃合、csh の nohup とか bash の disown とか全く無効になって
＃しまいますね。
--
しらい たかし
Tanaka Akira
shi...@nintendo.co.jp (Takashi SHIRAI) writes:
> ん？事実関係はともかくとして、その英文はこう訳すのが正しい
> ような気がするんですが。
> 「フォアグラウンドプロセスグループ以外の全てのプロセ
> スグループ。フォアグラウンドプロセスグループとは、制
> 御端末に関連づけられたセッションのメンバのこと。」
> 「that」が「,」を二つも跨いだ先を修飾していると捉えると、
> 「,」で区切られた部分が修飾的にしか働かないように扱われます
> が、この文の主題はむしろその「,」で区切られた部分では？
なぜですか?
英語の文法を自分自身の言葉で説明する自信はないので、google で「英語 文
法 カンマ」でひいてみたのですが、最初にでてきた
http://www5a.biglobe.ne.jp/~t-kite/koubun2.htm が私の解釈と一致します。
| ３、「挿入に気をつけよう」
|
| 一般にカンマとカンマにはさまれた所は、挿入が多い。カンマとカンマにはさまれた所を飛ば
| して、そこが文の構成上つながっていたら（文が成立したら）、カンマとカンマにはさまれた所
| は挿入と考えてほぼ間違いない。
そして、
Any process group, other than a foreground process
group, that is a member of a session that has established a connection with
a controlling terminal.
という文はまさにその例のように思えます。つまり , ではさまれた「other
than a foreground process group」の部分を飛ばして
Any process group that is a member of a session that has
established a connection with a controlling terminal.
としても文が成立するので、other than a foreground process group の部分
は挿入であり、that 以降は挿入部分ではなく Any process group を修飾して
いる、というのが私の解釈です。
つまり、私なりに訳すと、
制御端末と接続されたセッションのメンバであるすべてのプロセスグループ
(ただしフォアグラウンドプロセスグループを除く)
となります。
なぜ、other than a foreground process group の部分を挿入ではないと解釈
されたのでしょうか?
> ＃ それとも TIOCNOTTY された daemon 類は「background process
> ＃group」と呼んじゃいけないのかしらん？
私は(引用した文章により)呼ばないと解釈しています。
Noriyuki Soda
> 何だか話が噛み合ってませんね。渡邊さんの文章も私の文章も、
> 「制御端末」の定義によって真にもなるし偽にもなるという代物な
> ので、文章そのものの真偽ではなくてまずは「制御端末」の定義を
> 先に明確にすべきだと言っているんです。
shi...@nintendo.co.jp (Takashi SHIRAI) writes:
> そういうことであれば、私が「それは何をして『制御端末』と呼
> ぶかでしょう」と回答した時点で、「私はこれこれを『制御端末』
> と呼んでいます。そしてその意味に於いて制御端末とは．．．」と
> 続ければ良かったんじゃないでしょうか。
その必要はないと思いますよ。
UNIX の世界で前置きなく、制御端末という言葉が出てきた場合、
間違いなく渡邊さんの意味での制御端末を意味しますから。
(違う意味で使っている例を知らないんですが、もしあった場合には
著者の誤解の可能性が高いと思います。)
> それならば「はいそうですね」でおしまいです。
その通りだと思います。:-)
渡邊さんが問題を感じた
> つまり background process は端末を持たないことが判ります。
という表現は、
つまり端末は、foreground process group にだけ、シグナルを
送ることが判ります。
と書くのが、より正確だったわけです。
TIOCSPGRP に関する記述を「process が～持つ」と表現するのは、カーネルの
実装を知っている人間 (== 渡邊さん) には、違和感があるわけです。
・各 process は、制御端末を持っている。
(background になっても、やっぱり持っている。)
・端末は、foreground process group を持つ。
(TIOCSPGRP は、この foreground process group を設定する)
なわけですから…
--
so...@sra.co.jp Software Research Associates, Inc. 曽田哲之 (SODA Noriyuki)
Noriyuki Soda
> WATANABE Katsuhiro <ka...@watanabe.name> wrote:
> >2. ユーザが(bg proc. の制御)端末から logout した時などは、
> > bg proc. に SIGHUP が送られてきます。
渡邊さんの、この記述は不正確な気がします。
logout した時 (== セッション・リーダーが死んだ時)に カーネルがシグナル
を送るのは、foreground process group に対してだけじゃないでしょうか。
shi...@nintendo.co.jp (Takashi SHIRAI) writes:
> それは完全に shell のお仕事です。kernel の仕事ではありませ
> ん。background process に SIGHUP が送られるかどうかは shell
> の実装に依存します。
確かに {,t}csh なんかは、この種の処理をやっていますね。
# ある種の状況で、意図しないプロセスに SIGHUP が送られる経験を
# したことがあって、個人的には、この処理は余計なお世話だと
# 思ってますが。
が、
> 因みに Bourne shell の実装では、shell が process 制御を行
> なわない (fg も bg も非実装) ので、「&」で起動された process
> は logout 後も生き続けます。
この白井さんの記述も、また間違いだと思います。
もし、シェルがジョブ制御を全く行なわない場合には、「&」で
起動されたプロセスも、制御端末から見れば foreground process
group に属します。この場合、ログアウトする時に、(シェルでは
なく) カーネルから、SIGHUP が送られる筈です。
ただし、今では ジョブ制御を行なう bourne shell もあり (BSD 系の
/bin/sh である ash なんかもそうです)、そういう bourne shell では、
「&」で起動されたプロセスは、制御端末から見た background process group
に属します。この場合、確かにカーネルはプロセスにSIGHUP を送りませんし、
「&」で起動されたプロセスは logout 後も生き続けます。
しかし、これは「bourne shell がジョブ制御を行なわない」からでは
なく、「その bourne shell がジョブ制御を行なっている」からです。
つまり、白井さんの記述は、最終的な振舞いは合っているんですが、
原因は逆です。
昔々、ジョブ制御なんてものがなかったころは、nohup コマンドで
明示的に SIGHUP を無視するように指定しないと、background process
はログアウト時に殺されてしまったものでした。もし、その bourne shell が
ジョブ制御を行なわないものであれば、今でもそうなる筈です。
というわけで、ログアウト時に SIGHUP を送る処理を、「それは完全に shell
のお仕事です」と表現するのも、それはそれでまずいです。
> >3. bg proc. から出力を試みても、通常は SIGTTOU で停止しません。
>
> これも shell の実装依存の筈です。
これは、shell の実装には関係ないでしょう。
「stty -tostop」としてあれば、渡邊さんの書いたように動作しますし、
「stty tostop」としてあれば、白井さんの書いたように動作する筈です。
この stty の設定を無視してしまうような shell の実装が存在するので
しょうか?
> ＃ 但し、tty driver の実装によっては local mode LTOSTOP の
> ＃状態に依存します。
ここは、「tty driver がジョブ制御機能を有している限り常に、端末の
local mode として TOSTOP が設定されているか否かによって決まります」
と書くべきだと思います。
なお、tty driver がジョブ制御機能を有していない場合には常に、渡邊さん
の書いた通り、background でも止まらずに動作すると思います。
> その「端末に対する foreground process」という用法は POSIX
> で出て来た termios 用語だと思いますよ。
用語の方の起源は良く分からないんですが、概念自体は、TIOCSPGRP を
最初に実装した、4BSD が起源じゃないでしょうか。
Takahiro Kambe
> 本題に関係ないんですが、ついでなので
> > >3. bg proc. から出力を試みても、通常は SIGTTOU で停止しません。
> >
> > これも shell の実装依存の筈です。
>
> これは、shell の実装には関係ないでしょう。
> 「stty -tostop」としてあれば、渡邊さんの書いたように動作しますし、
> 「stty tostop」としてあれば、白井さんの書いたように動作する筈です。
> この stty の設定を無視してしまうような shell の実装が存在するので
> しょうか?
zshとかで、
% ttyctl -f
とかしとくと、シェルに制御が戻ってきた時点でttyのモードをresetします。
ただ、どこまで戻しているのかは確認していませんが。
もっとも、これはシェルの実装というよりも、追加機能の話しですね。
--
神戸 隆博, 株式会社ジェプロ(京都) / Takahiro Kambe, JEPRO Co., Ltd.
Takashi SHIRAI
In article <hvoznve...@coulee.a02.aist.go.jp>,
Tanaka Akira <a...@m17n.org> wrote:
>なぜ、other than a foreground process group の部分を挿入ではないと解釈
>されたのでしょうか?
挿入部分と捉えると、その部分は副次的なもので最も言いたい部
分はその後続部分ということになってしまいますよね。ということ
は、background process とは何かという説明では
第一義: 制御端末を持つこと
第二義: foreground でないこと
という優先順位になってしまい、これは逆なんじゃないかと思った
次第です。
background process の説明をする時に、どっちか片方だけ選ん
で説明しろと言われたら普通は後者を選びませんか？少なくとも前
者だけで済ませてしまうのはかなり誤解を招くと思うんですが。
＃ どっちの意味にしろ、もっと解釈のゆれが介在する余地の無い
＃文章にすれば良かったのに。
>> ＃ それとも TIOCNOTTY された daemon 類は「background process
>> ＃group」と呼んじゃいけないのかしらん？
>
>私は(引用した文章により)呼ばないと解釈しています。
その割には google で「daemon background-process」で検索か
けると、結構な数の「daemon = background process」的用法が見
つかりますね。正しい理解をしていない人が多過ぎるということな
んでしょうか。
制御端末を持たない process を background process group と
は呼ばない理由はどこかに書いてあったりしますか？そもそもそう
いうのは何に属するんでしょう？
1.foreground process group 扱い。
2.foreground でも background でもない特殊な process。
3.そもそも process group では無い。
多分、制御端末に対して fore/background と呼んでいるので 2.
になるということなんでしょうね。
--
しらい たかし
Takashi SHIRAI
In article <xqr1y8q...@srapc342.sra.co.jp>,
Noriyuki Soda <so...@sra.co.jp> wrote:
>もし、シェルがジョブ制御を全く行なわない場合には、「&」で
>起動されたプロセスも、制御端末から見れば foreground process
>group に属します。この場合、ログアウトする時に、(シェルでは
>なく) カーネルから、SIGHUP が送られる筈です。
では以下の挙動は kernel の実装ミスということになるんでしょ
うか？自宅なので多くの環境で試せなくて FreeBSD 2.2.6-RELEASE
でのみ確認していますが。
$ cat test.c
main()
{
if (!fork()) execl("/bin/sleep", "sleep", "3600", 0);
}
$ cc -o test test.c
$ ./test
$ exit
(telnet login し直す)
$ ps ux
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
shirai 509 3.1 0.9 764 852 p2 Ss 1:34AM 0:00.27 -bash (bash)
shirai 507 0.0 0.1 172 48 p2- I 1:34AM 0:00.00 sleep 3600
shirai 522 0.0 0.3 644 276 p2 R+ 1:35AM 0:00.00 ps -ux
$ kill 507
$ ps ux
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
shirai 509 0.0 0.9 764 852 p2 Ss 1:34AM 0:00.28 -bash (bash)
shirai 523 0.0 0.3 640 272 p2 R+ 1:36AM 0:00.00 ps -ux
$
この test.c は一体どこで job control を行なっているんでし
ょう？ちゃんと kill 出来るということは死に損ねた訳でもないよ
うです。勿論 SIGHUP の mask もいじってません。
>ただし、今では ジョブ制御を行なう bourne shell もあり (BSD 系の
それは「Bourne shell 系 shell」であって「Bourne shell」で
は無いと思います。少なくとも私はそれらを区別しています。ash
や ksh を「Bourne shell」とは呼びません。
＃ Steve Bourne なんかどこにも絡んでないし、source だってど
＃こをどう見たって全くの別物ですよね。Bourne shell の source
＃なんてそもそも C 言語にすら見えない :-)
>しかし、これは「bourne shell がジョブ制御を行なわない」からでは
>なく、「その bourne shell がジョブ制御を行なっている」からです。
>つまり、白井さんの記述は、最終的な振舞いは合っているんですが、
>原因は逆です。
少なくとも NEWS-OS 4.2.1 に実装されている /bin/sh は、man
page の記述によると job control を行なわないそうですが、「&」
付で起動した process は logout 後も生き続けていました。
NEWS-OS kernel も実装ミスを侵しているんですね？因みに正し
い挙動を示す UNIX kernel の例を教えて頂けないでしょうか？
>> これも shell の実装依存の筈です。
>
>これは、shell の実装には関係ないでしょう。
>「stty -tostop」としてあれば、渡邊さんの書いたように動作しますし、
>「stty tostop」としてあれば、白井さんの書いたように動作する筈です。
>この stty の設定を無視してしまうような shell の実装が存在するので
>しょうか?
その stty に相当する部分を shell が実装することによってど
うにでも変わるという意味で「shell の実装依存」と言った訳です。
実際はその辺りをいじる shell は知らないので「筈です」としま
した。
>> ＃ 但し、tty driver の実装によっては local mode LTOSTOP の
>> ＃状態に依存します。
>
>ここは、「tty driver がジョブ制御機能を有している限り常に、端末の
>local mode として TOSTOP が設定されているか否かによって決まります」
>と書くべきだと思います。
確かに舌足らずでしたね。「shell の実装依存」では意味が通じ
ないかと思って補足したつもりが却っておかしな表現になってしま
ったようです。
>> その「端末に対する foreground process」という用法は POSIX
>> で出て来た termios 用語だと思いますよ。
>
>用語の方の起源は良く分からないんですが、概念自体は、TIOCSPGRP を
>最初に実装した、4BSD が起源じゃないでしょうか。
TIOCSPGRP 自体はもっと前からあると思います。少なくとも以下
URL にある 2.9.1BSD の tty(4) には載っていますね。
http://www.freebsd.org/cgi/man.cgi?query=tty&apropos=0&sektion=4&manpath=2.9.1+BSD&format=html
--
しらい たかし
Takashi SHIRAI
In article <xqr3ct6...@srapc342.sra.co.jp>,
Noriyuki Soda <so...@sra.co.jp> wrote:
>> そういうことであれば、私が「それは何をして『制御端末』と呼
>> ぶかでしょう」と回答した時点で、「私はこれこれを『制御端末』
>> と呼んでいます。そしてその意味に於いて制御端末とは．．．」と
>> 続ければ良かったんじゃないでしょうか。
>
>その必要はないと思いますよ。
>UNIX の世界で前置きなく、制御端末という言葉が出てきた場合、
>間違いなく渡邊さんの意味での制御端末を意味しますから。
「前置きなく」ですよね？私が「それは TIOCSPGRP の意味」と
前置きした後も延々と「controlling terminal」の話を続けるので
「その必要」を説いたのですが。
わざわざ「制御端末」という単語で何を指すかが論点であると言
及した訳ですから、そこから後はその用法について意識して話を進
めるべきだと思います。
＃ 言葉の用法の間違いと事実認識の間違いとを意図的に混同して
＃いるように私には読めてしまった訳です。
>TIOCSPGRP に関する記述を「process が～持つ」と表現するのは、カーネルの
>実装を知っている人間 (== 渡邊さん) には、違和感があるわけです。
多分 shell 実装の観点からものを見過ぎた結果の表現だったん
でしょうね。別に私だってその辺りの話を知らない訳ではないんで
すけど。
shell から見ると、「自分の管理下の端末」「子の管理下の端末」
といった認識の仕方をしがちなので、持ち物的なイメージを抱いて
しまうんだと思います。
ただ、如何せん一年以上も前の記事ですよ。書いてあること自体
の意味は読み取れても、それをどういう意図で書いたかなんて憶え
てませんよ。
用語の用法なんて本筋とは直接関係ありませんからね。せいぜい
何を言いたかったのかまでしか憶えていられません。
＃ 延々と当たり前の知識を解説してくれるところを見ると、曽田
＃さんにも渡邊さんにも、単なる表現上の問題じゃなくてなんか余
＃程阿呆の子だと思われてんだろな．．．。
--
しらい たかし
Takashi SHIRAI
寝ぼけてました。訂正。
In article <ak5sr4$phm$2...@nsvn01.zaq.ne.jp>,
Takashi SHIRAI <shi...@nintendo.co.jp> wrote:
> しらいです。
>>もし、シェルがジョブ制御を全く行なわない場合には、「&」で
>>起動されたプロセスも、制御端末から見れば foreground process
>>group に属します。この場合、ログアウトする時に、(シェルでは
>>なく) カーネルから、SIGHUP が送られる筈です。
job control が無い訳なので、「&」付きも「&」無しも全部同一
の process group に属することになり、shell 自身が foreground
ならば子は全部 foreground ですね。考えてみれば当たり前の話で。
>$ cat test.c
>main()
>{
> if (!fork()) execl("/bin/sleep", "sleep", "3600", 0);
>}
>$ cc -o test test.c
>$ ./test
>$ exit
ここで login shell から起動しているのが良くない訳ですね。
そうしちゃうと都合 2 回 fork() されてしまって親子関係が切り
離されて、./test が死んだ途端に /bin/sleep は init に引き取
られてしまいますね。
./test を exec ./test として起動してやると、/bin/sleep は
一親等の子になってちゃんと死んでくれました。
> 少なくとも NEWS-OS 4.2.1 に実装されている /bin/sh は、man
>page の記述によると job control を行なわないそうですが、「&」
>付で起動した process は logout 後も生き続けていました。
これもひょっとしたら shell から /bin/sh を起動していたかも
知れません。
因みに、POSIX では shell は job control をすることになって
いますので、shell が SIGHUP を受取ると全ての子 process group
に SIGHUP を送ってから死ぬ仕様になっていたかと思います。
その話と Bourne shell とを混同していたみたいですね。
--
しらい たかし
Tanaka Akira
shi...@nintendo.co.jp (Takashi SHIRAI) writes:
> 挿入部分と捉えると、その部分は副次的なもので最も言いたい部
> 分はその後続部分ということになってしまいますよね。ということ
> は、background process とは何かという説明では
> 第一義: 制御端末を持つこと
> 第二義: foreground でないこと
> という優先順位になってしまい、これは逆なんじゃないかと思った
> 次第です。
つまり、background process に関する自分自身の考えにひきずられたわけで
すね。まぁ、しらいさんらしい、というところですか。
> background process の説明をする時に、どっちか片方だけ選ん
> で説明しろと言われたら普通は後者を選びませんか？少なくとも前
> 者だけで済ませてしまうのはかなり誤解を招くと思うんですが。
>
> ＃ どっちの意味にしろ、もっと解釈のゆれが介在する余地の無い
> ＃文章にすれば良かったのに。
両方説明すべきで、実際そうしているのでは?
すくなくとも私はあの文章を一意に解釈できたと思っていますし、問題ないと
思っています。
> その割には google で「daemon background-process」で検索か
> けると、結構な数の「daemon = background process」的用法が見
> つかりますね。正しい理解をしていない人が多過ぎるということな
> んでしょうか。
SUSv3 だけが正しく他は間違っているという立場をとるならば、そのとおりで
しょう。
でも、<hvo4rdnr4...@coulee.a02.aist.go.jp> の最後で触れたように、
他の定義・慣習もあるかも知れません。
> 制御端末を持たない process を background process group と
> は呼ばない理由はどこかに書いてあったりしますか？
私は知りません。
SUSv3 について十分に把握しているわけではありませんので、書いていないと
保証することもできませんが。
saitoh akinori
Takashi SHIRAI wrote:
> は、background process とは何かという説明では
> 第一義: 制御端末を持つこと
> 第二義: foreground でないこと
> という優先順位になってしまい、これは逆なんじゃないかと思った
> 次第です。
> background process の説明をする時に、どっちか片方だけ選ん
> で説明しろと言われたら普通は後者を選びませんか？少なくとも前
> 者だけで済ませてしまうのはかなり誤解を招くと思うんですが。
もともと引用されていた文章は、単独でbackground processを説明する
文章じゃないですよね。
job control とは、とか、processgroupとは、とかの定義が並んでいる中での
１項目としての説明ですから、それだけ取り出して、その解釈では
説明が不十分だというのは変でしょう。
白井さんの別の記事から白井さんによる訳文を引用しますが
> 「フォアグラウンドプロセスグループ以外の全てのプロセ
> スグループ。フォアグラウンドプロセスグループとは、制
> 御端末に関連づけられたセッションのメンバのこと。」
このように、「フォアグラウンドプロセスグループとは」という説明が
入るように訳すのは不自然ではないですか？。フォアグラウンドプロセ
スグループの定義は、ちゃんと別項目で存在するのですから。
http://www.unix-systems.org/でSUSv3を読んでみましたが、
(登録が必要ですが、無料です)、、、。
job control
session
process group
controlling terminal
あたりを読み比べた総合判断としては、
「制御端末を持たないプロセスグループforegroundでも backgroundでもない」
という解釈に齊藤は賛成です。
暇を見て、POSIXのほうも調べてみます。
4.[23]BSDの世界での用語では、jobはあくまでもコマンドインタプリタと
端末にまつわる用語なので、デーモン(サーバプロセス)はフォアグラウンド
でもバックグラウンドでもない、その枠外である、という解釈で特に
違和感はないのですけど。
saitoh akinori
Takashi SHIRAI wrote:
> 因みに、POSIX では shell は job control をすることになって
> いますので、shell が SIGHUP を受取ると全ての子 process group
> に SIGHUP を送ってから死ぬ仕様になっていたかと思います。
> その話と Bourne shell とを混同していたみたいですね。
ところでログアウト時に「カーネルが」SIGHUPを送るというのはどのUNIXでのの
はなしでしたっけ？
SystemVRel2のころの記憶ですが、＆つきで起動した子プロセスがそのまま残って、
起動したgettyが端末をオープンできるのだが制御端末とすることが出来ない
という症状に出会った記憶があります。
そのプロセスが処理を終わってexitしたら、ログインできましたが。
以前制御端末であったが今では対応づけを抹消されたttyへのファイルディスクリプタ
をreadしようとしたら、SIGHUPが送られるようなことはSUSv3に書いてあります。
Tanaka Akira
saitoh akinori <sai...@ics.es.osaka-u.ac.jp> writes:
> ところでログアウト時に「カーネルが」SIGHUPを送るというのはどのUNIXでのの
> はなしでしたっけ？
実は、セッションリーダーが死んだときに foreground process group に
SIGHUP が送られるというのは今回初めて知ったのですが、手元の FreeBSD は
たしかにそういう挙動を示します。そして _exit(2) には
o If the process is a controlling process (see intro(2)), the SIGHUP
signal is sent to the foreground process group of the controlling
terminal, and all current access to the controlling terminal is re-
voked.
と明記されています。SUSv3 にも exit() のところに同様な記述がありますし、
詳解 UNIX プログラミングにも各シグナルの説明のところで触れられています。
歴史的なことはわからないのですが、なんとなく古くからある機能な気がしま
す。動作から考えると job control を行なわない shell のための機能ですし。
(job control を行なう shell から exit/logout/^D などでログアウトした場
合、foreground process group は shell のみしか含まれていなくて、SIGHUP
の送り先が存在しないと思うので。)
# 端末が切断された時にセッションリーダーに SIGHUP が送られるのは知って
# いたんですが...
saitoh akinori
> In article <3D68F13D...@ics.es.osaka-u.ac.jp>,
> saitoh akinori <sai...@ics.es.osaka-u.ac.jp> writes:
> > ところでログアウト時に「カーネルが」SIGHUPを送るというのはどのUNIXでのの
> > はなしでしたっけ？
Tanaka Akira wrote:
> 歴史的なことはわからないのですが、なんとなく古くからある機能な気がしま
> す。
ですよね。
僕の記憶でも、かなり昔に得た知識の中にこれがあるのです。
もしかすると、SystemVとBSDに分かれる前からの機能かなぁと
思ったのですが。
ku...@gssm.otsuka.tsukuba.ac.jp
sai...@ics.es.osaka-u.ac.jpさん:
> 僕の記憶でも、かなり昔に得た知識の中にこれがあるのです。もしか
> すると、SystemVとBSDに分かれる前からの機能かなぁと思ったのです
> が。
nohup.1はV6にありますね。
http://minnie.tuhs.org/UnixTree/V6/usr/man/man1/nohup.1.html
ただ、V6では「カーネルが」送るのじゃないような気がします。ライオ
ンズ本ならあるのでざっとexitのところを見てみたけどそれらしいこと
はしていなようだし。V6ではシェルがやっていたのかも。上記のサイト、
shのソースもあると思うんだけど見つからない…
V7になるとBourne Shellが入りますから、ここでカーネルに入ったと
いう説はありかな。そういえば、AT&T系はジョブコントロールの代りに
shl(shell layer)を使っていましたよね。
shlって触ったことがない… 久野
Takashi SHIRAI
In article <3D68EF02...@ics.es.osaka-u.ac.jp>,
saitoh akinori <sai...@ics.es.osaka-u.ac.jp> wrote:
>大阪大学の齊藤です
>> 「フォアグラウンドプロセスグループ以外の全てのプロセ
>> スグループ。フォアグラウンドプロセスグループとは、制
>> 御端末に関連づけられたセッションのメンバのこと。」
>このように、「フォアグラウンドプロセスグループとは」という説明が
>入るように訳すのは不自然ではないですか？。フォアグラウンドプロセ
>スグループの定義は、ちゃんと別項目で存在するのですから。
複数の修飾節があって、それぞれが何を修飾しているかを明確に
表すためにその部分を補って訳した訳ですが、foreground process
group の項も合わせて読んでみるとそういう意味でもなさそうです
ね。
>http://www.unix-systems.org/でSUSv3を読んでみましたが、
>(登録が必要ですが、無料です)、、、。
SUSv2 ならば登録の必要も無いようなので読んでみたところ、こ
ちらでも同様の説明文になっていました。foreground の方は SUSv3
の方を見ていないので比較出来ませんけど。
http://www.unix-systems.org/single_unix_specification_v2/xbd/glossary.html
＃ ただ、background の方の説明に foreground が出て来て、同
＃様に foreground の方にも background が出て来るという定義文
＃は無限ループに陥ってしまうんじゃないだろか？ :-)
>4.[23]BSDの世界での用語では、jobはあくまでもコマンドインタプリタと
>端末にまつわる用語なので、デーモン(サーバプロセス)はフォアグラウンド
>でもバックグラウンドでもない、その枠外である、という解釈で特に
>違和感はないのですけど。
冷静に判断してみると、background というのは foreground の
対比として存在する単語なので、いずれは foreground になり得る
という意味も暗に含んでいるかも知れません。
そういう意味では、daemon は永遠に foreground にはなり得ま
せんから、普通の background process group とは区別して捉える
べきなんでしょう。
直感的概念の「裏で動いているプロセス」として一緒くたに捉え
てしまうと駄目なんだと思いますが、得てして直感的概念の方が判
り易いので、私も含めて誤認してしまう人が多いんじゃないかな？
--
しらい たかし
saitoh akinori
Takashi SHIRAI wrote:
> 冷静に判断してみると、background というのは foreground の
> 対比として存在する単語なので、いずれは foreground になり得る
> という意味も暗に含んでいるかも知れません。
そうなんでしょうね。
とくに、バックグラウンド「ジョブ」がバックグラウンドプロセスグループと
同義になっているところから、そう感じます。
「daemonはバックグラウンドプロセスグループだ」という主張にはそうかもしれ
ないなぁ？と思いますが、「daemonはバックグラウンドジョブだ」といわれると、
「daemonにはジョブコントロールは効かないじゃないか」と言いたくなります。
> そういう意味では、daemon は永遠に foreground にはなり得ま
> せんから、普通の background process group とは区別して捉える
> べきなんでしょう。
> 直感的概念の「裏で動いているプロセス」として一緒くたに捉え
> てしまうと駄目なんだと思いますが、得てして直感的概念の方が判
> り易いので、私も含めて誤認してしまう人が多いんじゃないかな？
そうですね。
UNIXでのから離れてOS一般では、インタラクティブでないプロセス全般を
バックグラウンドというと思います。あ、batchは除くかな？
当初のUNIXでは
&つきで起動→バックグラウンド
nohupかつ&つきで起動→バックグラウンド
&なしで起動→フォアグラウンド
daemon → 正式用語なし。バックグラウンドと呼ぶこともあり。
だったのではないでしょうか。
ジョブコントロールが導入されて話が複雑になっちゃいました。
セッショングループとか端末グループとか、いろいろな概念を導入しないと
いけなくなった。
KATAYAMA Yoshio
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> nohup.1はV6にありますね。
> http://minnie.tuhs.org/UnixTree/V6/usr/man/man1/nohup.1.html
ところが、V7 では消えて、Sys III で復活しています。
>ただ、V6では「カーネルが」送るのじゃないような気がします。ライオ
>ンズ本ならあるのでざっとexitのところを見てみたけどそれらしいこと
>はしていなようだし。V6ではシェルがやっていたのかも。上記のサイト、
>shのソースもあると思うんだけど見つからない…
exit(2) に SIGHUP の記述が出てくるのは Sys III からです。
＃ BSD 系はマニュアルがないので未確認です(_ _)
V7 までは現在の意味のプロセスグループがありませんでしたから、カー
ネルがログアウトで SIGHUP を送るのは難しいと思います。この環境で
は、sh が「自分が本当にログインシェルである」ことを判断するのも
難しいと思いますので、やはり SIGHUP を送るのは難しいと思います。
V6 の nohup は、回線切断（端末の電源断や電話回線の切断）で発生す
る SIGHUP のためではないでしょうか。
--
片山＠ＰＦＵ
Takashi SHIRAI
In article <3D6ACD47...@ics.es.osaka-u.ac.jp>,
saitoh akinori <sai...@ics.es.osaka-u.ac.jp> wrote:
>大阪大学の齊藤です
>「daemonはバックグラウンドプロセスグループだ」という主張にはそうかもしれ
>ないなぁ？と思いますが、「daemonはバックグラウンドジョブだ」といわれると、
>「daemonにはジョブコントロールは効かないじゃないか」と言いたくなります。
私も確かに foreground か background かはともかく「job」に
は違和感を感じます。でも、「job」では無いものの「process」の
一つではあるという認識があるので直感的違和感があるんでしょう
ね。
SUSv2 だと「background process」というのはまず「background
process group」ありきで、その一員として「background process」
が初めて成立していることになっています。
daemon の場合は「background process group」として認められ
ないが故に「background process」としても認められなくなってし
まい、その辺りが直感的違和感に繋がるんじゃないでしょうか。
>当初のUNIXでは
>&つきで起動→バックグラウンド
>nohupかつ&つきで起動→バックグラウンド
>&なしで起動→フォアグラウンド
>daemon → 正式用語なし。バックグラウンドと呼ぶこともあり。
>だったのではないでしょうか。
この時点では fore/background という概念の主体は飽くまでも
操作する人間であって、端末がどうのというのは副次的なものだっ
たんじゃないかと思います。
それが、端末を主体に捉える定義が現れたところで非直観的な用
法になっていったんじゃないでしょうかね。
>ジョブコントロールが導入されて話が複雑になっちゃいました。
>セッショングループとか端末グループとか、いろいろな概念を導入しないと
>いけなくなった。
どうしてそういう複雑さを覚悟の上で fore/background という
名称を敢えて使ったんでしょうね？shell から見た「&」の有無と
いう従来の概念とは直行する名称を何か考えれば良かったのに。
この辺りの実装は、実際の仕組み以上に名称のせいで必要以上に
ややこしい印象を与えてしまっているような気がします。
＃ job control の難しさは勿論名称だけじゃないけど。
--
しらい たかし
KATAYAMA Yoshio
shi...@nintendo.co.jp (Takashi SHIRAI) writes:
>>当初のUNIXでは
>>&つきで起動→バックグラウンド
>>nohupかつ&つきで起動→バックグラウンド
>>&なしで起動→フォアグラウンド
>>daemon → 正式用語なし。バックグラウンドと呼ぶこともあり。
>>だったのではないでしょうか。
手元にある最も古いマニュアルは V6 なので“当初”ではないかもしれ
ませんが、既に daemon という用語が出ています。
> この時点では fore/background という概念の主体は飽くまでも
>操作する人間であって、端末がどうのというのは副次的なものだっ
>たんじゃないかと思います。
> それが、端末を主体に捉える定義が現れたところで非直観的な用
>法になっていったんじゃないでしょうかね。
daemon と control terminal（v6 では controle typewriter）関係は、
最初から深いものだったと思います。
v7 以前は現在の意味の process group はなく、複数のプロセスにシグ
ナルを送る方法は同一の control terminal（&& 同一の UID）を持つプ
ロセス全部に送るしかありませんでした。このようなシグナルを安心し
て送れる（= daemon が死なない）ようにするには、control terminal
から切り離すしかなかったからです。
--
片山＠ＰＦＵ
WATANABE Katsuhiro
田中 哲 <a...@m17n.org> さんいはく
> > 「background process も制御端末を持つことがある」
>
> 常に持つ気がします。
>
> SUSv3 によれば、
おっしゃる通りです。SUSv3 での定義は、私にもしっくりきます。
私の２つの記事での話の展開方法にしらいさんは多々ご不満があろうかと
思いますが、広く一般の方を念頭に記事を書いたということもありますので、
ぎこちなさを容じてやってください。今後は改善に努めます。
--
渡邊克宏 http://katsu.watanabe.name
Takashi SHIRAI
In article <KATE.02Au...@flash.tokyo.pfu.co.jp>,
KATAYAMA Yoshio <ka...@pfu.fujitsu.com> wrote:
>> この時点では fore/background という概念の主体は飽くまでも
>>操作する人間であって、端末がどうのというのは副次的なものだっ
>>たんじゃないかと思います。
>> それが、端末を主体に捉える定義が現れたところで非直観的な用
>>法になっていったんじゃないでしょうかね。
>
>daemon と control terminal（v6 では controle typewriter）関係は、
>最初から深いものだったと思います。
ん？私の書いたのは、「端末を主体として fore/background と
いう概念が昔は無かった」という意味での「主体」であって、関係
の有無や深浅には言及していないんですが。
それともその深い関係というのは、前景か背景かという意味に於
いて深度が深いという意味での「深い」なんですか？
少なくとも、daemon 以外の process に関する当時の fore/back-
ground の概念は、interactive な interface がその process を
待ってくれているか否かという点に起因していて、端末との関係か
ら生じたのではないように思えます。
daemon 以外の process にとっては、shell の実装により結果的
に、直感的な fore/background の概念と端末を主体とした fore/
background の概念が一致したので混乱は生じなかったけど、daemon
にとっては端末を主体として fore/background を語れないために、
直感的な fore/background の概念との間のずれが生じたのでない
かという話です。
>v7 以前は現在の意味の process group はなく、複数のプロセスにシグ
>ナルを送る方法は同一の control terminal（&& 同一の UID）を持つプ
>ロセス全部に送るしかありませんでした。このようなシグナルを安心し
>て送れる（= daemon が死なない）ようにするには、control terminal
>から切り離すしかなかったからです。
これなんですけど、job control の存在しなかった時代は init
が看取ってやれずに zombie 化することが多かったと思うんですが、
そういう zombie とたまたま同じ UID と端末で login した場合、
その端末から派生した process と zombie とはどう区別出来たん
でしょう？
＃ 最近の UNIX だと滅多に zombie を見ないのでなかなか検証出
＃来ません。
--
しらい たかし
Tanaka Akira
ka...@pfu.fujitsu.com (KATAYAMA Yoshio) writes:
> exit(2) に SIGHUP の記述が出てくるのは Sys III からです。
>
> ＃ BSD 系はマニュアルがないので未確認です(_ _)
BSD 系のソースを眺めてみました。
カーネルのソースは眺め慣れていないものであまり自信がありませんが、セッ
ションリーダーの exit に伴う foreground process group への SIGHUP の送
信を行なうコードは Reno にありますが、Tahoe には見当たりません。つまり、
導入されたのはあまり古いことではないようです。
考えてみると BSD では job control は有るのが当たり前なわけで、job
control のない shell のための処理を加える価値はあまりなかったのかもし
れません。
Takahiro Kambe
> カーネルのソースは眺め慣れていないものであまり自信がありませんが、セッ
> ションリーダーの exit に伴う foreground process group への SIGHUP の送
> 信を行なうコードは Reno にありますが、Tahoe には見当たりません。つまり、
> 導入されたのはあまり古いことではないようです。
sessionの概念が導入されたのは、4.4BSD pre-release的な位置付けであった
4.3BSD renoからです。
--
神戸 隆博 / Takahiro Kambe
KATAYAMA Yoshio
shi...@nintendo.co.jp (Takashi SHIRAI) writes:
>>daemon と control terminal（v6 では controle typewriter）関係は、
>>最初から深いものだったと思います。
> ん？私の書いたのは、「端末を主体として fore/background と
>いう概念が昔は無かった」という意味での「主体」であって、関係
>の有無や深浅には言及していないんですが。
ここは、
>>>>daemon → 正式用語なし。バックグラウンドと呼ぶこともあり。
>>>>だったのではないでしょうか。
>>> この時点では fore/background という概念の主体は飽くまでも
>>>操作する人間であって、端末がどうのというのは副次的なものだっ
>>>たんじゃないかと思います。
に対して、端末がどうのというのは副次的ではないという意味です。
> 少なくとも、daemon 以外の process に関する当時の fore/back-
>ground の概念は、interactive な interface がその process を
>待ってくれているか否かという点に起因していて、端末との関係か
>ら生じたのではないように思えます。
私の主張は、background と daemon の関係に言及するなら、control
terminal（の有無）が重要であるということです。
>daemon
>にとっては端末を主体として fore/background を語れないために、
>直感的な fore/background の概念との間のずれが生じたのでない
>かという話です。
しらいさんの主張が分からなくなってきました。daemon にも
fore/background があるといことでしょうか。
> これなんですけど、job control の存在しなかった時代は init
>が看取ってやれずに zombie 化することが多かったと思うんですが、
>そういう zombie とたまたま同じ UID と端末で login した場合、
>その端末から派生した process と zombie とはどう区別出来たん
>でしょう？
区別できなかったのではないかと思います。しかし、区別する必要もな
かったのではないでしょうか。
--
片山＠ＰＦＵ
Takashi SHIRAI
In article <KATE.02Au...@flash.tokyo.pfu.co.jp>,
KATAYAMA Yoshio <ka...@pfu.fujitsu.com> wrote:
>>>> この時点では fore/background という概念の主体は飽くまでも
>>>>操作する人間であって、端末がどうのというのは副次的なものだっ
>>>>たんじゃないかと思います。
>
>に対して、端末がどうのというのは副次的ではないという意味です。
なるほど。つまり、「fore/background という概念の主体は飽く
端末であって、操作する人間にとってどうのというのは副次的なも
のだった」と主張されたい訳ですね。
元から人間を主体とした直感的概念ではなく端末を主体とした形
式的な概念だったということですか。となると、その頃は process
と端末とがどういう関係にあった時に「background」と称したんで
しょう？
>>daemon
>>にとっては端末を主体として fore/background を語れないために、
>>直感的な fore/background の概念との間のずれが生じたのでない
>>かという話です。
>
>しらいさんの主張が分からなくなってきました。daemon にも
>fore/background があるといことでしょうか。
UNIX の実装に拘らずに直感的な解釈をするならば、daemon の存
在を「background」と言っても良いのではないかというだけのこと
です。
そういう直感的な見方と、実際の UNIX 上での呼称とが合ってい
ないことが誤解の元になっているのではないでしょうか。
>> これなんですけど、job control の存在しなかった時代は init
>>が看取ってやれずに zombie 化することが多かったと思うんですが、
>>そういう zombie とたまたま同じ UID と端末で login した場合、
>>その端末から派生した process と zombie とはどう区別出来たん
>>でしょう？
>
>区別できなかったのではないかと思います。しかし、区別する必要もな
>かったのではないでしょうか。
ということは、子 process を kill しようと意図したソフトな
のに zombie まで含めて kill してしまうという可能性もあったん
でしょうね。それで実際に zombie が死ぬかどうかは別として。
--
しらい たかし
Shigenobu Kimura
> In article <KATE.02Au...@flash.tokyo.pfu.co.jp>,
> KATAYAMA Yoshio <ka...@pfu.fujitsu.com> wrote:
> >>>> この時点では fore/background という概念の主体は飽くまでも
> >>>>操作する人間であって、端末がどうのというのは副次的なものだっ
> >>>>たんじゃないかと思います。
> >
> >に対して、端末がどうのというのは副次的ではないという意味です。
>
> なるほど。つまり、「fore/background という概念の主体は飽く
> 端末であって、操作する人間にとってどうのというのは副次的なも
> のだった」と主張されたい訳ですね。
操作する人は, 端末を通して行なうわけだから, 端末が
主体であろうと人間が主体であろうと fore/background の
概念に矛盾ないでしょう？
それと, 片山さんは, foreground/backgournd と言う概念は
端末と密に結び付いているという事実を指摘してるだけで
何かを主張してるようには見えませんが....
> 元から人間を主体とした直感的概念ではなく端末を主体とした形
> 式的な概念だったということですか。
私は, ここで問題になっている UNIX の foreground/background
名前の付け方は十分直観的だと思います.
> UNIX の実装に拘らずに直感的な解釈をするならば、daemon の存
> 在を「background」と言っても良いのではないかというだけのこと
> です。
これはまぁ, いいとはおもうけど,
今まで UNIX の話をしてたんじゃないの？
> そういう直感的な見方と、実際の UNIX 上での呼称とが合ってい
> ないことが誤解の元になっているのではないでしょうか。
多分そうでしょう. でも誤解してるのしらいさんだけだよ.
> ということは、子 process を kill しようと意図したソフトな
> のに zombie まで含めて kill してしまうという可能性もあったん
> でしょうね。それで実際に zombie が死ぬかどうかは別として。
そもそも zombie に signal 送れないと思うのだけど....
たとえ送れたとしてなにか困ることあるんでしょうか？
ちょっと思いつきません.
木村 栄伸
KATAYAMA Yoshio
shi...@nintendo.co.jp (Takashi SHIRAI) writes:
>>に対して、端末がどうのというのは副次的ではないという意味です。
> なるほど。つまり、「fore/background という概念の主体は飽く
>端末であって、操作する人間にとってどうのというのは副次的なも
>のだった」と主張されたい訳ですね。
そうです。daemon と background の区別には、control terminal の有
無が重要ということです。
> 元から人間を主体とした直感的概念ではなく端末を主体とした形
>式的な概念だったということですか。となると、その頃は process
>と端末とがどういう関係にあった時に「background」と称したんで
>しょう？
daemon - control terminal を持たない
background - control terminal を持つ（かつ終了を待ち合わせている
shell がいない）
> UNIX の実装に拘らずに直感的な解釈をするならば、daemon の存
>在を「background」と言っても良いのではないかというだけのこと
>です。
システムによっては、Unix の foreground、background、daemon が、
foreground - TSS
background - バッチジョブ
daemon - システムタスク
に相当するものもあります。Unix に拘らないというのでしたら、この
ようなシステムで、バッチジョブとシステムタスクを同一視するような
ものです。これは受け入れ難い解釈です。
> そういう直感的な見方と、実際の UNIX 上での呼称とが合ってい
>ないことが誤解の元になっているのではないでしょうか。
しらいさんの background(*) ではそういう見方が直感的なのかもしれ
ませんが、それが万人に受け入れられるとは限らないと思います。
＊ V7 のドキュメントで background を grep したら、こっちの意味の
＊方が多かった ;-p
>>区別できなかったのではないかと思います。しかし、区別する必要もな
>>かったのではないでしょうか。
> ということは、子 process を kill しようと意図したソフトな
>のに zombie まで含めて kill してしまうという可能性もあったん
>でしょうね。それで実際に zombie が死ぬかどうかは別として。
zombie は既に終了したプロセスなので、シグナルを送ること自体がで
きなかったはずです。
--
片山＠ＰＦＵ
Shinji KONO
In article <ako6m7$ql3$1...@nsvn01.zaq.ne.jp>, shi...@nintendo.co.jp (Takashi SHIRAI) writes
> なるほど。つまり、「fore/background という概念の主体は飽く
>端末であって、操作する人間にとってどうのというのは副次的なも
>のだった」と主張されたい訳ですね。
なんか授業で、Mac OS XとかX-Window とかを使いながら、^Z とか
fg, bg を教えているのを後ろから見ていて、「なんか、時代遅れ
な感じがする...」と思っていたことを思い出します..
もはや、^z なんて必要ないんだけど... いきなり別Window
が開く方が実用的かな?
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
ku...@gssm.otsuka.tsukuba.ac.jp
> もはや、^z なんて必要ないんだけど... いきなり別Window
> が開く方が実用的かな?
いやあ、suspendしたいことはありますよ。「今この先まで処理が進
むと困るなあ」と思ったら^Zが一番簡単。
psしてkill -STOPしてもいいけど 久野
Shinji KONO
In article <akv5f1$1m...@utogw.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp writes
> いやあ、suspendしたいことはありますよ。「今この先まで処理が進
>むと困るなあ」と思ったら^Zが一番簡単。
で、ずるずる表示がでていて、なかなか止まらなかったりするんで
すよね～
いらないといいつつ、手が勝手に^zしているんだよな～
一つは、OS Xにうつって、キーボードでターミナルを切り替えられ
ないからなんだが...
saitoh akinori
Takashi SHIRAI wrote:
> ということは、子 process を kill しようと意図したソフトな
> のに zombie まで含めて kill してしまうという可能性もあったん
> でしょうね。それで実際に zombie が死ぬかどうかは別として。
zombieとは、プロセスのexitした後の姿で、まだwaitしてもらってないので、
プロセステーブルエントリが残っているものです。
zombie自身にシグナルを送って、その結果でzombieが居なくなることはないと思います
が。
HASHIMOTO, Tsuyoshi
> 私の２つの記事での話の展開方法にしらいさんは多々ご不満があろうかと
（傍目で）これまでの話の流れから受けた感じで、今にして思えば ...
元々のしらいさんの記事では、「background process は端末をもたない」
と書いてあって、「制御端末を持たない」とは書いてなかったので、
例えば、「しらいさんの記事での「端末をもたない」とは「その端末
からの入力を受け付けない」などと表現する方が、誤解されにくいと
思います。Unix 的には background process も制御端末は持っているので。」
などと枕を置いて制御端末の話に移れば、「あたりさわりがなかった」
ような気はします。:-)
議論の途中で出た OS 一般での用語、あるいは「厳密ではないかも知れ
ないが、よく見掛ける使い方」での background についても、例えば、
http://www.dictionary.com/ で background （あるいは foreground）を検索して、
jargon としての用法を見れば出てくるので、もう少しとげとげしくない
言葉で議論が進んでもよかったように思います。
あと、daemon という用語を同じ URL で検索して出てきた定義を見て思った
のですが、daemon という言葉は、起源としては「働き方」に注目していて
端末と切り離すかどうかという実装手段の観点から定義された用語では
ないので「制御端末との関係での background process かどうか」という問題
の立て方自体、必ずしも「きちんと割りきれる答がある」とは言えないと
いう感じもします。
例えば pagedaemon などが、いわゆる kernel process として実装されている場合、
「端末との関係」を議論するのは mismatch な感じですが、「jargon としての
意味での background で動いている何か」と捉える事には、特に違和感は感じ
ません。
--
橋本 剛