Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!rutgers!clyde!cbosgd!mandrill!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: ^C works strangely on this terminal.
Message-ID: <6908@ncoast.UUCP>
Date: 27 Dec 87 18:07:38 GMT
References: <435@minya.UUCP>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 65

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.]