Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #16166

Re: looking for consistent C-c trap behavior

Show key headers only | View raw

On 4/17/20 3:59 PM, gentoo_eshoes--- via Bug reports for the GNU Bourne
Again SHell wrote:
> I've noticed that if I trap SIGINT in a bash script, the behavior when encountering C-c depends on whether an external command (eg. 'sleep 100') or a builtin command (like 'read -p') was encountered.

It's only `read', and it happens when bash is executing in default mode.
Here's what I wrote (off-list) earlier this month about it; it has come
up several times before:

=====
The idea is that trapping the signal doesn't interrupt the read, kind of
like a read system call getting restarted if interrupted by a signal and
reading from the terminal. Since the read doesn't get interrupted, you have
to satisfy it by entering newline. If you didn't have the trap on INT it
would interrupt the read.

Bash has behaved this way in its default mode for just about forever. In
posix mode, it interrupts the read system call.
=====

The behavior of running the trap action and restarting the read if it
returns is still there in default mode for backwards compatibility.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: looking for consistent C-c trap behavior Chet Ramey <chet.ramey@case.edu> - 2020-04-18 16:03 -0400

csiph-web