Sender: katsu@FLAGSHIP Newsgroups: fj.os.bsd.freebsd,fj.os.bsd.netbsd,fj.unix.shells Subject: Re: sh trap wait References: <9e2890$2cm$1@sc6.osa.sharp.co.jp> <9e39lu$3h3$1@nsvn01.zaq.ne.jp> From: WATANABE Katsuhiro Date: 13 Aug 2002 10:52:22 +0900 Message-ID: Organization: An individual person. User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Lines: 28 Xref: FLAGSHIP mine:443 あまりの follow-up の遅さが議論の妨げになっていたらごめんなさい。 しらい たかし さんが 記事 <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)になっていないからでしょう。 -- 渡邊克宏 http://katsu.watanabe.name