On Mon, 1 Sept 2025 at 14:48, Oğuz <oguzismailuy...@gmail.com> wrote:
> On Sunday, August 31, 2025, Maria <mariaca...@proton.me> wrote: > > > Bash exiting early with an exit code > > indicating a signal using nothing but a command line does not > > sound like expected behavior to me. > The « >(…) » construct was a game changer, especially when used as the target of output redirection as « > >(…) ». It meant that it became trivially easy to wind up in a situation where a built-in being executed by the main shell process could trigger a fatal SIGPIPE; previously you could only do that by redirecting to a named pipe, which was a relative rarity especially for login shells. (People who did that knew that they needed to trap SIGPIPE.) > What else should happen instead? echo is a shell builtin, when its write > end is a broken pipe, the shell performing it receives a signal. There is > nothing unexpected about this. Are you saying an interactive shell should > handle signals gracefully when it's executing builtin commands? > Well, if it's waiting for a subprocess to exit, it won't be writing anything, so it doesn't matter what its disposition of SIGPIPE is. So it could be handled similarly to how an interactive shells handles SIGINT and SIGQUIT; mostly, to leave the handler installed all the time, but resetting to the default in the child of any fork. (One difference is that SIGINT & SIGQUIT get delivered to a process group, while SIGPIPE is delivered to a single process, so there's no need to bother forwarding signals. There might be other tweaks needed but it doesn't seem insurmountable.) -Martin
