Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

Hi, I'm forwarding a bug report originally reported in . When a builtin function like echo fails to write to a named pipe, bash will receive a SIGPIPE that will terminate the whole shell. To reproduce this issue: In shell 1: $ rm -f /tmp/f && mkfifo /tmp/

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci wrote: > The command in the first shell will exit after a random number of > iterations with "terminated with exit status 141". That's what every other shell does. > Regardless of the reason for the SIGPIPE, the reporter expects the loop > to carr

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

On 21/03/24 18:08, Oğuz wrote: On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci wrote: Regardless of the reason for the SIGPIPE, the reporter expects the loop to carry on indefinitely (`while true; ...`). Then he should do `trap '' PIPE' before the loop. it is incorrect that > SIGPIPE termi

Re: ${var@A}; hypothetical, related parameter transformations

On 3/20/24 3:05 PM, Zachary Santer wrote: That expansion will produce a declare command if the variable has any attributes, since it needs one to reproduce them. If the variable has a value, but no attributes, you'll get an assignment statement. If there are no attributes and no value, you get

Re: ${var@A}; hypothetical, related parameter transformations

On 3/20/24 4:30 PM, Zachary Santer wrote: The point I'm trying to make is that ${var@A} expanding to either a declare command, an assignment statement, or nothing, depending on potentially changing criteria, is unnecessarily cumbersome. In whatever circumstances where a bash programmer would act

Re: Bash printf should diagnose integer overflow

On 3/19/24 11:48 PM, Paul Eggert wrote: On 3/18/24 12:41, Chet Ramey wrote: I'm not sure what you're using, but that was not my experience on macOS. I am using Fedora 39 (the current version) on x86-64. That could explain our differing experiences. I see several diagnostics (mostly diff out

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

On 3/21/24 12:13 PM, Gioele Barabucci wrote: When bash runs a builtin command without forking, it should install a SIGPIPE handler that will cause that signal to abort the command but not terminate the shell. If this behavior is desired and not considered a bug, then the bash manual should desc

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

On 3/21/24 1:43 PM, Gioele Barabucci wrote: On 21/03/24 18:08, Oğuz wrote: On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci wrote: Regardless of the reason for the SIGPIPE, the reporter expects the loop to carry on indefinitely (`while true; ...`). Then he should do `trap '' PIPE' before the

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

On 21/03/24 22:54, Chet Ramey wrote: On 3/21/24 1:43 PM, Gioele Barabucci wrote: On 21/03/24 18:08, Oğuz wrote: On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci wrote: Regardless of the reason for the SIGPIPE, the reporter expects the loop to carry on indefinitely (`while true; ...`). Then

Re: Bash printf should diagnose integer overflow

On 2024-03-21 13:31, Chet Ramey wrote: Interesting. I can't reproduce this. Using the commit to which your patches apply, without applying any of them, on a fresh Virtualbox Fedora 39 install, I get consistent `make tests' output every time. I just now tried the latest devel commit (b1e7f6803