Skip to content

Conversation

@ChrisDryden
Copy link
Collaborator

@ChrisDryden ChrisDryden commented Dec 11, 2025

Work in progress for me trying to understand the whole EPIPE situation, on one hand the GNU implementation is supposed to clearly return a 1 in this case, but when the ignore sigpipe is set it should return 0 and we don't have that in any of the utilities. I think the plan could be set this for now and when the library that all of the utilities use for ignoring the sig-pipe is made we add it here.

@github-actions
Copy link

GNU testsuite comparison:

Congrats! The gnu test tests/seq/seq-epipe is no longer failing!

@pixelb
Copy link

pixelb commented Dec 11, 2025

There must have been a misunderstanding in the original code before this change. GNU seq never returns 0 upon pipe error. The shell implicitly handles SIGPIPE result from any command, which I guess is the source of the misunderstanding. For the record seq (or any properly behaving unix command) returns failure upon any pipe error. See:

$ env --ignore-signal=PIPE seq inf | :
seq: write error: Broken pipe
$ echo ${PIPESTATUS[@]}
1 0

$ seq inf | :
$ echo ${PIPESTATUS[@]}
141 0

pipes being central to the unix model, this is a critical thing to get right,
though it is an often misunderstood signal, as I've detailed at:
https://www.pixelbeat.org/programming/sigpipe_handling.html

@ChrisDryden
Copy link
Collaborator Author

Started working on a draft that is way more comprehensive and is able to pass all of the GNU pipe signal related tests based on @mattsu2020 's handler #9646 will be separating the shared library and the seq fixes into a separate PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants