Re: SIGINT kills interactive shell from dot script
On 11/7/16 7:54 AM, Martijn Dekker wrote: > But it's really helped that bash turns out to have another unique > behaviour: apparently, bash refuses to ignore SIGINT on interactive > shells. So, for interactive bash, the workaround is simply to avoid > using "trap - INT" to unignore the signal. What do you mean? If you run 'trap "" SIGINT' in an interactive shell, bash will let you happily pound on ^C on your keyboard all day long without doing anything. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: In ((0? var: 0)), expressions stored in var are evaluated.
On 11/6/16 9:39 PM, Koichi MURASE wrote: > Hello, here is another bashbug report. Thanks for the report and fix. This is a nice job of investigation. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
Re: SIGINT kills interactive shell from dot script
Op 08-11-16 om 14:38 schreef Chet Ramey: > On 11/7/16 7:54 AM, Martijn Dekker wrote: > >> But it's really helped that bash turns out to have another unique >> behaviour: apparently, bash refuses to ignore SIGINT on interactive >> shells. So, for interactive bash, the workaround is simply to avoid >> using "trap - INT" to unignore the signal. > > What do you mean? If you run 'trap "" SIGINT' in an interactive shell, > bash will let you happily pound on ^C on your keyboard all day long > without doing anything. Some more experimenting showed inconsistent behaviour, so it's another bug, not a feature. I had misinterpreted the behaviour as a feature due to wishful thinking, because it looked so convenient as a workaround for the interactive-shell-exits-on-SIGINT bug in my shell library. Here's what I've been able to determine so far. SIGINT fails to be ignored on interactive shells if both of the following two conditions are met: - the SIGINT trap is non-empty (i.e. contains a command, even a simple ':' will do); - the command(s) to be interrupted are not issued on the same command line as the command to set the SIGINT trap. Examples follow (using POSIX code so you can test it on any other shell). Works as expected: The 'trap' command is on the same command line as the loop. The signal is properly ignored, the trap is properly executed repeatedly on pressing Ctrl+C. $ trap 'echo INT' INT; i=0; while [ $((i+=1)) -lt 100 ]; do :; done ^CINT ^CINT ^CINT $ echo $? $i 0 100 Buggy behaviour: The 'trap' command is on a separate command line. The signal is not ignored. The trap is executed once on Ctrl+C and the loop is interrupted. $ trap 'echo INT' INT $ i=0; while [ $((i+=1)) -lt 100 ]; do :; done ^CINT $ echo $? $i 130 60985 Behaviour confirmed on bash-4.4 down to 2.05b. Interestingly, the exit status behaviour for this bug test is inconsistent on various bash versions. Some random ones I've tried: - bash 4.4 produces exit status 130, the correct one for SIGINT. - bash 4.3.39 on NetBSD produces exit status 130. - /bin/bash 4.2.53 on Slackware 14.1 produces exit status 128. - /bin/bash 4.1.17 on Slackware 13.37 produces exit status 128. - /bin/bash 3.2.57 on Mac OS X 10.11.6 produces exit status 1. - bash 2.05b produces exit status 1. Hope this clarifies, - M.
Re: The trap EXIT not allways executed
FYI: This works in 4.3.42 (echos "ATT: execute trap function" in both).
Dr. Werner Fink wrote
The trap EXIT not allways executed, see example script
Repeat-By:
Example script
#!/bin/bash
bash -c '
_rm () { echo ATT: Execute trap function; }
trap _rm EXIT
rm -f doesnotexist
'
echo $?
bash -c '
_rm () { echo ATT: Execute trap function; }
rm -f doesnotexist
trap _rm EXIT
'
echo $?
which results in
0
ATT: Execute trap function
0
Changelog credit objection
>From CWRU/CWRU.chlog in git: >10/19 > >- > > variables.c > > - get_bashpid: BASHPID is no longer readonly; assignments to it are > > just ignored. Suggested by Martijn Dekker > I object to the impression given that I would suggest any such thing. In fact I think ignoring assignments is very bad practice and I recall arguing rather forcefully against it: https://lists.gnu.org/archive/html/bug-bash/2016-10/msg00066.html I appreciate being credited for bug reports, but please remove my name from this entry. Thanks, - M.
Re: The trap EXIT not allways executed
On 11/7/16 5:09 AM, Dr. Werner Fink wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.4 > -L/home/abuild/rpmbuild/BUILD/bash-4.4/../readline-7.0 > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu' > -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fmessage-length=0 > -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong > -funwind-tables -fasynchronous-unwind-tables -g -D_GNU_SOURCE > -DRECYCLES_PIDS -Wall -g -Wuninitialized -Wextra -Wno-switch-enum > -Wno-unused-variable -Wno-unused-parameter -Wno-parentheses > -ftree-loop-linear -pipe -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0 -fprofile-use > uname output: Linux noether 4.1.34-33-default #1 SMP PREEMPT Thu Oct 20 > 08:03:29 UTC 2016 (fe18aba) x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-suse-linux-gnu > > Bash Version: 4.4 > Patch Level: 0 > Release Status: release > openSUSE Bug: 1008459 > > Description: > The trap EXIT not allways executed, see example script Thanks for the report. This will be fixed in the next devel branch update. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
