>>> As for SIGTSTP and other tty signals, the signal should be sent to
>>> the process group rather than to just the current process.
>> I disagree.
> Take a look at curses(3) and other SIGTSTP-aware software.  You will
> easily find kill(0, SIGTSTP).

So?  Just because other software is broken is no reason for us to write
more broken software.  (I wasn't aware of this bug in curses; it really
ought to be fixed.  Thanks for pointing it out.)

> Stopping only one process of a process group will cause serious
> problems with BSD job control and must be avoided.

Right.  So?  As I wrote, if it was generated from the tty, it's already
been sent to the rest of the process group.  If it was generated with
kill(), then either it's already been sent to the rest of the process
group or it shouldn't be sent to the rest of the process group.

> BSD is carefully designed to allow kill(0, SIGTSTP) in the former
> case.  Sending SIGTSTP to already stopped processes is ignored
> happily.

Yes...if the process happens to be stopped at that point.  Which it may
not be, for any of various reasons.

> In the latter case ["If it was sent to this process specifically"],
> stopping one process of a process group may left the terminal in
> unusable state, and stopping the process group is user's benefit.

That's as may be.  But it is not for us to make that decision; that is
for the signal's sender to decide.  If the signal was sent to us and no
other process, it is not for us to say that it should be rebroadcast to
others; we should behave as much as possible like a process with no
handling installed, which does *not* include re-sending the signal
anywhere.  "Unix does not prevent you from doing stupid things because
that also prevents you from doing clever things."

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B