bash does not run exit traps if the last command is a kill builtin that kills bash (`kill "$$"')
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
-DNON_INTERACTIVE_LOGIN_SHELLS
uname output: Linux t420 5.15.35-1-lts #1 SMP Wed, 20 Apr 2022
11:49:16 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Bash does not run `EXIT' traps if the last command is the kill
builtin kills that kills the shell.
Maybe because of some incorrect optimisation?
Repeat-By:
bash-5.1$ bash -c 'trap echo\ x EXIT; kill "$$"'
Terminated
bash-5.1$ bash -c 'trap echo\ x EXIT; { kill "$$" ;}'
Terminated
bash-5.1$ bash -c 'x () { trap echo\ x EXIT; kill "$$"; }; x'
Terminated
bash-5.1$ bash -c 'trap echo\ x EXIT; echo a; kill "$$"'
a
Terminated
bash-5.1$ bash -c 'trap echo\ x EXIT; kill "$$"; :'
x
Terminated
bash-5.1$ bash -c 'trap echo\ x EXIT; /bin/kill "$$"'
x
Terminated
bash-5.1$ bash -c 'x () { trap echo\ x EXIT; kill "$$"; }; x; :'
x
Terminated
I have been able to reproduce this bug in bash5, bash4, and
bash3.
The EXIT trap is run correctly in bash2.
Re: bug#54785: for floating point, printf should use double like in C instead of long double
On 4/25/22 3:06 PM, Paul Eggert wrote: On 4/25/22 11:22, Chet Ramey wrote: Thanks for the input. You're welcome. Whenever you decide what to do about this, could you please let us know? I'd like coreutils printf to stay compatible with Bash printf. Thanks. I think I'm going to stick with the behavior I proposed, fixing the POSIX conformance issue and preserving backwards compatibility, until I hear more about whether backwards compatibility is an issue here. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Bug in documentation (man)
Hi Gnu, I bash 5.1 man it says that pipeline may consist of single command. So "echo foo" is a pipeline. It also says that each command in pipeline runs in a subshell, therefore "echo foo" runs in a subshell. But thats not true. Regards Gasan
Re: bug#54785: for floating point, printf should use double like in C instead of long double
On 4/29/22 13:04, Chet Ramey wrote: I think I'm going to stick with the behavior I proposed, fixing the POSIX conformance issue and preserving backwards compatibility, until I hear more about whether backwards compatibility is an issue here. Come to think of it, as far as POSIX is concerned Bash doesn't need to change what it does. POSIX doesn't require that the shelll printf command be compiled with any particular environment. It would conform to POSIX, for example, if Bash's printf were compiled with an IBM floating point implementation rather than with an IEEE floating point implementation, so long as Bash's printf parses floating-point strings the way strtod is supposed to parse strings on an IBM mainframe. Similarly, Bash's printf can use an 80-bit floating point format if available; it will still conform to POSIX. So this isn't a POSIX conformance issue; only a compatibility issue. Is it more important for the Bash printf to behave like most other shells and other programs, or is it more important for Bash printf to behave like it has for the last 18 years or so?
