Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Feb 1998 02:21:27 +0100
From:      Martin Cracauer <cracauer@cons.org>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        cracauer@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-bin@FreeBSD.ORG, cvs-committers@FreeBSD.ORG
Subject:   Re: cvs commit: src/bin/sh jobs.c
Message-ID:  <19980207022127.48731@cons.org>
In-Reply-To: <199802061928.GAA07506@godzilla.zeta.org.au>; from Bruce Evans on Sat, Feb 07, 1998 at 06:28:44AM %2B1100
References:  <199802061928.GAA07506@godzilla.zeta.org.au>

next in thread | previous in thread | raw e-mail | index | archive | help
> I thought we were still discussing it.  I didn't like it before, and
> like it less now.  The committed version has the following bugs:

I backed it out. 
 
> 1) SIGINT/SIGQUIT are not restored after fork failure.

That just needs 
        if (oldsigs_valid) {
               signal(SIGQUIT,oldsigquit);
               signal(SIGINT,oldsigint);
               oldsigs_valid = 0;
        }
in the (pid == -1) clause.


> 2) SIGINT/SIGQUIT are always reset to SIG_DFL in the child.  This is
>    wrong if these signals are ignored on entry to the shell.

Under what circumstances will a child be entered with ignored signals?

One use I can think of is spawning subshells in a shellscript. If
signals are always resetted to default, subshells will be exited at
once and the whole shellscript will be terminated on one. This is also
what bash and pdksh do. So below for an example.

I don't think ignoring signals is useful for any fork() that is to be
followed by exec(). Everything else is a subshell and therefore part
of the script which should exit as a whole on the first SIGINT.

> 3) SIGTERM apparently needs to be handled like SIGINT/SIGQUIT.  bash
>    seems to handle it like that.

SIGTERM is a different matter. What I'm trying to fix are characters
that can be generated from a terminal keyboard and will therefore be
used for asynchronous actions by applications.

> I'm testing the following fix:
[diff ommited]

Two test cases where your and my solutions differ:

1)
  #!/usr/src/bin/sh.work/sh 
  emacs -nw
  while `true` ; do foo=1 ; done

After emacs exits, your version exits the loop only on SIGINT. SIGQUIT
and SIGTERM are ignored. My solution exits on all three signals.

2) 
#!/usr/src/bin/sh.work/sh 
(
    (
        emacs -nw
        while `true` ; do foo=1 ; done
    )
    while `true` ; do foo=1 ; done
)
while `true` ; do foo=1 ; done

After exiting emacs, my version drops out of all subshells and
terminate the whole script on one SIGINT, which I think is the right
thing to do. Your version needs three to exit the script. As I said,
bash and pdksh need only one as well.

And your version ignores both SIGQUIT and SIGTERM, which probably
isn't intended.

I also managed to bring you version into endless
  sh in malloc(): warning: recursive call.
several by sending mixed signals, but I can't remember the exact
sequence for now, sorry.

I know that my solution is ugly, but it so far it does what I think is
the right thing in all cases.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
  cracauer@wavehh.hanse.de (batched, preferred for large mails)
  Tel.: (daytime) +4940 41478712 Fax.: (daytime) +4940 41478715
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
  Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980207022127.48731>