Conceptually this sounds useful, but how exactly would it work?
• Is any attempt made to terminate the other processes in the pipeline, or
to you just not delay by waiting for them immediately?
→ If attempting to terminate:
- using which signal?
- what happens if the process refuses to die?
→ If allowing them to continue in the background:
- can the script learn the pids of the incomplete parts of the pipeline
- can it explicitly wait for them (as if they were ordinary background
processes, or otherwise)
- if the script doesn't wait for them, when should Bash reap them?
• Normally it's expected that if any part of a pipeline exits, all
preceding parts would eventually receive SIGPIPE upon writing to stdout.
Would you treat the parts to the left of the terminated part differently
from the parts to its right? How? Would there be any other positional
differences?
• How would this interact with pipefail or lastpipe?
-Martin
---------- Forwarded message ---------
From: ama bamo <pythoncont...@gmail.com>
Date: Tue, 25 Jun 2024, 02:21
Subject: Proposal for a New Bash Option: failfast for Immediate Pipeline
Failure
To: <bug-bash@gnu.org>
Dear Bash Maintainers,
I have encountered a challenge with the current implementation of pipelines
in Bash, specifically regarding subshells and the pipefail option. As
documented, each command in a pipeline is executed in its own subshell, and
Bash waits for all commands in the pipeline to terminate before returning a
value.
To address these issues, I propose the introduction of a new option,
failfast, which would immediately terminate the pipeline if any command in
the pipeline fails. This would streamline error handling and provide more
predictable script execution, aligning with user expectations in many
common use cases.
Here is an example illustrating the proposed behavior:
````
#!/bin/bash
set -o failfast
nonexisting-command | sleep 10# Pipeline exits immediately without
sleeping for 10 seconds
````
This would provide a more intuitive and robust error handling mechanism for
pipeline commands, enhancing the usability and reliability of Bash
scripting.
I look forward to your feedback.
Best regards,
Mateusz Kurowski
