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 [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/
