[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: ctrl-C and command lists
From:       Chet Ramey <chet.ramey () case ! edu>
Date:       2008-09-22 21:36:06
Message-ID: 48D80FC6.2010400 () case ! edu
[Download RAW message or body]

Julian Bradfield wrote:
> In every other shell I've used, the behaviour of ctrl-C in an
> interactive shell is to interrupt the current command-line and return
> to the shell prompt.
> This is, I think, the behaviour expected by the user in almost all
> circumstances. In the rare circumstance when one doesn't want to do
> that, traps can be used.
> 
> Historically, bash has taken the approach that ctrl-C interrupts the
> currently executing pipeline, but that's all. That results in the mad
> panic when one does:
> 
> for f in * ; do destroy $f ; sleep 1; done
> oh-shit-ctrl-C-ctrl-C-ctrl-C-oh-shit-ctrl-Z-I-hate-bash!
> 
> I see that the most recent bash has now changed its behaviour so
> that ctrl-c breaks out of any executing loops, thereby solving the
> above problem.
> 
> However, as pointed out recently by "jidanni" in RISKS 25.31, bash
> still executes the rest of a list:
> 
> sleep 360000 ; launch_shuttle
>  oops, found a problem with the O-rings, ctrl-C
> VROOM!
> 
> 
> I argue that bash should do what the user expects: in the absence of
> traps, SIGINT should return to the prompt.

I will make this change for the next version.  Keep in mind that it's a
problem because of the way job control works -- unless other arrangements
are made, bash doesn't get the SIGINT sent to the foreground process
group.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/



[prev in list] [next in list] [prev in thread] [next in thread]