[ruby-dev:31117] Re: $&;[] dumps core

In article <[e-mail]>,
  SASADA Koichi <[e-mail]> writes:

>> そのせいか、^C 一発で止まらないのですが、そんなことはありませんか?
>
> 　止まりません。
>
> 　で、これは誰も返事をしていない [ruby-dev:31007] の話だとは思
> いますが、これはどうするべきなんでしょうか。私は、1.8 がこうい
> う挙動なので、こういうもんだと思っていました。どうすると幸せな
> 人が増えるのかは、経験不足でわかりません。実装についてもよくわ
> かりません。

止めようと思って ^C を入力しているのに、止まらないのは不幸です。

> ruby 1.8:
> perl:
> python:

うぅむ。ruby 以外にもあったのか。

In article <E1I5MXU-0006WF-3w@x31>,
  Yukihiro Matsumoto <[e-mail]> writes:

> rb_syswait()がSIGHUP, SIGQUIT, SIGINTをSIG_IGNに設定している
> からですね。で、これがなぜそうしているかというと、実は私にも
> わからないのですが、直接的な理由はPerlの真似をしたからだった
> と思います。

予想外にあったので、起源をたどってみると、どうも、C の
system からして止まらないようですね。

SUS の system の項に解説があって以下のように書いてあります。
http://www.opengroup.org/onlinepubs/007904975/functions/system.html#tag_03_757_07

    Note that, while system() must ignore SIGINT and SIGQUIT and block SIGCHLD
    while waiting for the child to terminate, the handling of signals in the
    executed command is as specified by fork() and exec. For example, if SIGINT
    is being caught or is set to SIG_DFL when system() is called, then the
    child is started with SIGINT handling set to SIG_DFL.

    Ignoring SIGINT and SIGQUIT in the parent process prevents coordination
    problems (two processes reading from the same terminal, for example) when
    the executed command ignores or catches one of the signals. It is also
    usually the correct action when the user has given a command to the
    application to be executed synchronously (as in the '!' command in many
    interactive applications). In either case, the signal should be delivered
    only to the child process, not to the application itself. There is one
    situation where ignoring the signals might have less than the desired
    effect. This is when the application uses system() to perform some task
    invisible to the user. If the user typed the interrupt character ( "^C",
    for example) while system() is being used in this way, one would expect the
    application to be killed, but only the executed command is killed.
    Applications that use system() in this way should carefully check the
    return status from system() to see if the executed command was successful,
    and should take appropriate action when the command fails.

つまり、
* 子プロセスだけが生き残って、端末を取り合うとかのことを避ける
* vi の ! みたいなものでユーザが実行した時には ^C は子プロセスだけが死ぬべき
という理由があるようです。

しかし、この扱いがよろしくないケースもあることがあげられてい
ます。これは具体的にはユーザからは見えないところで system を
使う、というケースで、bootstraptest はまさにその例と考えられ
ます。そして、そのケースではアプリケーションが注意深く
system の返り値を検査すべきである、とも書かれています。

ということは、Ruby の system (や ``) が C の system の仕様を
引き継いでいるとすると、bootstraptest で、system の返り値
(というか、`` だから $?) を適切に検査していないのが問題であ
る、ということになります。

なんで検査しないんですか?

あるいは、C や Perl のように例外がない世界から Ruby のように
例外がある世界に移った時点で、API を変えるべきなのではないか、
ということも考えられます。

子プロセスだけが生き残るのはたしかにあまりよろしくないように
思いますが、vi の ! みたいなのは system の用法としてあまり多
いとは思えないので気にしないことにして、子プロセス実行中に
SIGINT がきたら、子プロセスが死んだ後に Interrupt 例外が発生
するとかはどうでしょうか。

でも、C の system を使って実装するのは無理かな...
-- 
[田中 哲][たなか あきら][Tanaka Akira]