bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: looking for consistent C-c trap behavior


From: Chet Ramey
Subject: Re: looking for consistent C-c trap behavior
Date: Sat, 18 Apr 2020 16:03:55 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]