jc@minya.UUCP (John Chambers) (12/21/87)
Hi there. You might remember a month or so ago I described a bit
of unusual behavior, in which this terminal somehow ignored ^C,
although we have the the usual setup where stty says:
intr = ^c; quit = ^x; erase = ^h; kill = ^z; swtch = ^`;
Nobody came forth with a useful response to that one. But I have
some further evidence now. As part of installing the recent solution
to the question of how you get `pwd` into PS1 in a Bourne shell, I
turned off a line in our /etc/profile that used to say:
trap "" 1 2 3
This line apparently caused the strange behavior, since it no longer
happens. What happens instead is even more curious. Now ^C causes
the running program to die, and also the shell dies, logging me out!
I've seen this behavior before; I have another program which, when
it exits normally, the shell also exits (though I wouldn't call that
'normally' :-). Why, I'm not sure. But I suspect that what is going
on is that a signal is going to both my program and also to the shell.
Does anyone have any explanation? Is there a reliable way to get a
Sys/V to automagically pass signals to both a process and also to its
parent? Is there a way to make it stop doing this? Is this all just
a fignewton of my imagination? Stay tuned....
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)allbery@ncoast.UUCP (Brandon Allbery) (12/28/87)
As quoted from <435@minya.UUCP> by jc@minya.UUCP (John Chambers): +--------------- | Hi there. You might remember a month or so ago I described a bit | of unusual behavior, in which this terminal somehow ignored ^C, >... | turned off a line in our /etc/profile that used to say: | trap "" 1 2 3 | happens. What happens instead is even more curious. Now ^C causes | the running program to die, and also the shell dies, logging me out! | Does anyone have any explanation? Is there a reliable way to get a | Sys/V to automagically pass signals to both a process and also to its | parent? Is there a way to make it stop doing this? Is this all just | a fignewton of my imagination? Stay tuned.... +--------------- Here we go again.... Okay. UNIX, both the System V and BSD variants, can be set to send a signal upon receipt of a specific character (you use ^C). However, since UNIX doesn't have the concept of a "current process" (DOWN WITH PROCESS DISCRIMINATION! ;-) the signal is sent to all processes in the process group led by the process opening the terminal. (Excuse the odd wording, it's not necessary under SV but is somewhat relevant to BSD's job control mechanism.) In other words, the ^C sends a signal to all your processes (I saw a "swtch", I'll assume you don't have job control). Now: Only rarely (if ever) is that "trap" line above used by itself; usually, there are two paired "trap" lines, often set up as follows: trap : 2 cat /etc/motd trap 2 The idea is to allow the user to interrupt the message of the day without blowing away the sourcing of /etc/profile. I'd hazard a guess that you got one "trap" line and not the other(s); and that something else in /etc/profile on your system requires interrupts disabled. Quick synopsis of "trap": trap [action] signal ... action may be missing, which clears a trap. If action is '' or "", the trap is ignored. (This is not the same as being cleared; if cleared, the trap will abort the shell.) Both the above will affect any programs started by the shell. action may also be a shell command line, in which case the commands will be executed on receipt of the signal; these kind of traps are never passed on to programs started by the shell, they instead have the trap cleared. Signal 2 is SIGINT, caused by the "intr" character (^C) Signal 3 is SIGQUIT, caused by the "quit" character (^\) Most of the semantics here are of signal(2), e.g. the system call, NOT something the shell does specially. So: your /etc/profile was doing a 'trap "" 2', which causes ^C to be ignored. Somewhere else, therefore, it was doing a "trap 2" to restore the signal. I would check for this, if necessary reloading the original unmodified /etc/profile off a backup (you *do* keep backups, don't you?), and make sure that any traps set are cleared by the end of the script. Send mail if you want me to be a bit clearer; I tried to be concise at the (possible) expense of understandability. -- Brandon S. Allbery, Moderator of comp.sources.misc {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery [This space reserved for future quotes and similar brain twisters.]