more on this....
One of our unix gurus emailed me this:
susp in stty does tsusp signal generation, same thing. So it does look
good from here. Next thing to look at is whether or not the shell is
properly setting up process groups and, particularly, the pgrp of the tty.
I don't know an easy way to check the pgrp of the tty other than writing a
program (BSD sps does it, but it's unlikely you have that program). Now,
just about everything except the old old /bin/sh does that right (and
/bin/sh is just /bin/ksh in HP/UX if I remember right so even that should
work) ... if it can. But there is a case in which it can't.
It's particularly likely that the pgrp stuff is wrong since posix has some
whacked limitations on who can set the tty pgrp. In BSD (where process
groups evolved) any process with access to the tty could set the pgrp. In
posix they changed it so only a process in the same tty session could
change it. If the tty session isn't properly set up then the shell can't
change the pgrp of the tty and signal generation will fail just like you're
seeing. The job of setting that up falls to the terminal program, so if
you're seeing it with one terminal program and not another that could
explain it.
This is typically verifiable with some simple code:
int main()
{
int sid = getsid();
int ppgrp = getpgrp(getppid());
int pgrp = getpgrp();
int tty_pgrp = tcgetpgrp();
/* look to see if parent process is session root */
if (ppgrp != sid) {
printf ("shell pgrp is not the same as session ID\n");
printf ("sid = %d\n", sid);
printf ("ppgrp = %d\n", ppgrp);
}
else
printf ("shell pgrp looks OK\n");
/* look to see if this pid is is in foreground pid on the tty */
if (pgrp != tty_pgrp)
printf ("process isn't the foreground process(expected pgrp %d, got %d)\n", pgrp, tty_pgrp);
else
printf ("tty pgrp looks ok\n");
}
>Ok, got this:
>
>shell pgrp is not the same as session ID
>sid = -1
>ppgrp = 19387
>process isn't the foreground process(expected pgrp 19387, got -1)
Well, that means it's totally broken -- nobody set the session ID when the
pty was set up, and if it's not set then the shell can't do the tty
foreground process configuration and if that's not done then tty-generated
signals don't work (which is what you're seeing).
The only way this happens is if the terminal program neglected to do it or
failed in the attempt. The latter is fairly likely, actually, since a lot
of terminal programs got their start on BSD-derived systems. Those
programs would work under Solaris but will not work under a purer POSIX
system like HP/UX.
My first suggestion would be to try a different terminal program. Failing
that there's a kind of bootstrap way to do it (have the shell exec a
program that sets things up correctly, then have the program re-exec the
shell) but I've not done it in a loooong time, and it varies by OS and even
version of OS, so I can't do that off the top of my head.
so maybe someone here has a better idea of why I am getting these results, and better yet, how to fix them?
