Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16174
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: looking for consistent C-c trap behavior |
| Date | 2020-04-19 15:16 -0400 |
| Organization | ITS, Case Western Reserve University |
| Message-ID | <mailman.710.1587323784.3066.bug-bash@gnu.org> (permalink) |
| References | <M58iOBd--3-2@tutanota.com> <a8b7d5fc-0a64-0a0e-bd49-7f808f937813@case.edu> <M5EEHGq--3-2@tutanota.com> <dc44f492-ce44-463a-685e-58ecddf38888@case.edu> |
On 4/18/20 5:41 PM, gentoo_eshoes@tutanota.com wrote: > can confirm that indeed `bash --posix` does interrupt the 'read -p' on first C-c, however, the inside-trap seen exit code is 0, but if the trap doesn't `exit` itself, then the exit code after the 'read -p' is seen correctly as 130, ie. > $ ./sigintread.bash > Press C-c here...^Cinterrupted sees exit code '0' > > Normal exit sees ec=130 > > Would it be possible to somehow get 130 even inside the trap function? > > this would then be equivalent with interrupting 'sleep' for example: > $ ./sigintread.bash > ^Cinterrupted sees exit code '130' > > Normal exit sees ec=130 This is a reasonable idea for posix mode, since the trap action is run after the read command returns. > On another note, I naively tried to patch out the POSIX requirement, for my own/local_use puposes but had no effect: This (from bashline.c) is for readline support. The `read -e' comment is true. -- ``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
Re: looking for consistent C-c trap behavior Chet Ramey <chet.ramey@case.edu> - 2020-04-19 15:16 -0400
csiph-web