trap command

UNIX for Beginners Q & A UNIX for Dummies Questions & Answers
1

I'm learning about the trap command from my bash book. I tried out the little script they gave:

trap "echo 'You hit control-C!' " INT
while true; do
	sleep 60
done

But when I type control-c, the script just stops and the message is not displayed. I checked stty all and saw that control-c is intr, but the same thing happened whet I tried that. Can anyone tell me what I'm missing?

I'm using terminal (BSD) in OS X

2

kill -l (lowercase L) lists the names of your signals. stty -a shows terminal settings.

Look for something like these in login profiles:

trap "" 2 3
trap 2 3
trap 'exit' 2
trap 'kill $$' 2

SIGINT = 2 on almost all systems.

The first turns off the signal in your login profile(s). trap 2 3 enables them. trap 'exit' 2
specificaly converts SIGINT into an exit command. trap 'kill $$' converts SIGINT into SIGTERM the default for kill.

3

I don't follow. Why would my book use int instead of numbers?

And when I run the script and control-c all I get is

^C

on the screen and the cursor keeps blinking

4

The syntax of the command is

trap  "command "  [signal name or signal number]

So, that said, you want to see if a trap already exists in your shell. I would say that yes, one does. And it ignores SIGINT (or 2). Why it exists I can't say. You need to work on that one. So, that is why I suggest looking at all of the various login profiles you have on your box. /etc/profile, $HOME/.profile, .kshrc, or .bashrc ---- whatever.

5

I agree with the rest that the signal is somehow disabled.

Whether you have INT or 2 in the signal name, this could be a better construct for a test script because it lets you exit the script.

trap 'echo You hit control-C!;exit' INT
while true; do
sleep 60
done

Perhaps try positively setting the key as the first line of the script.

stty intr '^C'
6

Methyl:
I tried setting the key but it didn't work:

stty: illegal option -- INT
usage: stty [-a|-e|-g] [-f file] [options]
trap: usage: trap [-lp] [arg signal_spec ...]

I wish I had a unix manual of some sort --

I typed trap -l and got this (on my iMac at home -- still the same result when I ran the script) :

1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGABRT 7) SIGEMT 8) SIGFPE
9) SIGKILL 10) SIGBUS 11) SIGSEGV 12) SIGSYS
13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGURG
17) SIGSTOP 18) SIGTSTP 19) SIGCONT 20) SIGCHLD
21) SIGTTIN 22) SIGTTOU 23) SIGIO 24) SIGXCPU
25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH
29) SIGINFO 30) SIGUSR1 31) SIGUSR2

so I'm guessing that the interrupt signal is SIGINT.

Even with this, the same thing happens -- ^C is displayed on the screen and it goes right back to the script. If I type control z it says this :

[1]+ Stopped sleep 60

and goes right back to the script -- and the job number increases by one every time I type it. I can't stop the script from running. The only way I can is to quit terminal, at which point I get a message saying the following processes will be stopped -- bash, and however many sleep jobs it's running.

7

Methyl -- and anyone else:

It's been a while since I've been here, but I've got something else.

I fooled around with some other scripts and got it to print a message -- are you getting it to display the message?

Here's a script that I did today:

It works fine -- the numbers zip by and get larger and larger. If I hit control - c I can see the message -- it's only a flash. If I put sleep 10 in the script after the echo command,and hit control-c, all I get is ^C displayed on the screen, but no message. I'm wondering if the message is displayed briefly, but so quickly that I can't see it. Am I not typing the command correctly and not noticing it, maybe?

If i try this script

It works fine. The message is displayed:

I think it has something to do with the sleep command, but I can't figure out why. Do you have any ideas?

8

Whatever is running in the foreground gets interrupted by ctrl-c. when sleep is running, it gets interrupted and not your shell.

read is a shell builtin, not an external command, so when it's waiting on read, your shell is still in the foreground.

9

Okay -- but I still don't get why the message isn't displayed. Other folks can get it. Any idea why not me? My book says it should display the message and go right back to the loop.

Sorry if it's a basic question, but I'm still new to this.

10

No they don't, not when their shell's not the foreground process.

When you're running an external command, your shell isn't the foreground process, so the signal doesn't get delivered to it. It gets delivered to the foreground process instead, in this case, sleep, which causes it to quit and return a non-zero error code:

$ sleep 30
^C
$ echo $?
130
$

This is because the process isn't actually killed by the shell -- it's killed directly, by you. The terminal device translates control-C directly into SIGINT for you. What the 'foreground process' is isn't a property of the shell, either -- it's a property of the terminal itself, so it always knows where to send SIGINT direct.

This is true only if your shell is the foreground process. If it's in the middle of running any externals, your shell's not in the foreground.

11

I'm sorry to be so dense corona, but can you tell me what is meant by external command, foreground process, etc. I'm not sure the book is clear on this. :o

12

An external command is one that's not built into the shell. It exists as an actual file somewhere, and when you run it, it creates a whole new process.

$ whereis -b cat
cat: /bin/cat
$ /bin/cat file.txt
contents of file
$ whereis read
read:
$ read VAR
qwertyuiop
$ echo $VAR
qwertyuiop
$

builtins, on the other hand, are commands the shell just automatically knows how to do. There's no 'read' program on the system, but 'read' works anyway, putting the qwertyuiop typed on the keyboard into the variable VAR.

So when you run an external command, it's run seperately, and it has control of the terminal until it's done. When you run an internal command, no programs are run, the shell just does what you tell it internally.

Another important builtin is one you probably already know -- 'cd'. Consider how external programs are run -- they have a separate process, their own environment. If cd wasn't a builtin it couldn't possibly work, because it'd create a new process, change that process' directory, quit, and return to your shell, leaving your shell unchanged.