Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

treat SIGPIPE as normal termination by default? #1469

Closed
StefanKarpinski opened this issue Oct 29, 2012 · 2 comments
Closed

treat SIGPIPE as normal termination by default? #1469

StefanKarpinski opened this issue Oct 29, 2012 · 2 comments
Assignees
Labels
needs decision A decision on this change is needed
Milestone

Comments

@StefanKarpinski
Copy link
Member

See this comment from John Cowan:

In general, Julia's command execution is far more careful (aka finicky) when it comes to termination status of subprocesses than the shell or other programming languages.

I very much agree that this is the Right Thing in general, but I also strongly believe that SIGPIPE should be treated as normal termination. Pipes are essentially a form of lazy data stream connecting two coroutines, in which the consumer resumes the producer when it needs more input. If the consumer chooses not to read from the producer, this ought not to be treated as a fault in the producer, which is what any other sort of signal would mean. The reason for SIGPIPE to happen at all is to prevent useless processes from hanging about with nowhere to send their output to.

In particular, using ignorestatus on any occasion when the consumer might terminate spontaneously without reading all of its input ("sed q" is just one such case), which in principle can mean any process that writes to a pipe, will wind up masking actual errors (the best is the enemy of the good). It should be possible to determin that a SIGPIPE has occurred, of course, but it should not propagate an error into the controlling process.

@Keno
Copy link
Member

Keno commented Jun 25, 2013

I believe treating SIGPIPE as normal termination is right. Any objections to me implementing that?

@StefanKarpinski
Copy link
Member Author

No, I think it's the right thing to do.

@Keno Keno closed this as completed in fb79518 Jun 25, 2013
vtjnash added a commit that referenced this issue Apr 21, 2021
This error code does not exist on Windows, so any code that relied on
this was broken (would fail this test) on that platform already. In most
cases, it was actually a serious error too, such as `cp -v` or `tar -v`,
which will indeed fail midway and give corrupt results if you do not read
their output to completion!

Reverts #1469, in essence
ElOceanografo pushed a commit to ElOceanografo/julia that referenced this issue May 4, 2021
This error code does not exist on Windows, so any code that relied on
this was broken (would fail this test) on that platform already. In most
cases, it was actually a serious error too, such as `cp -v` or `tar -v`,
which will indeed fail midway and give corrupt results if you do not read
their output to completion!

Reverts JuliaLang#1469, in essence
antoine-levitt pushed a commit to antoine-levitt/julia that referenced this issue May 9, 2021
This error code does not exist on Windows, so any code that relied on
this was broken (would fail this test) on that platform already. In most
cases, it was actually a serious error too, such as `cp -v` or `tar -v`,
which will indeed fail midway and give corrupt results if you do not read
their output to completion!

Reverts JuliaLang#1469, in essence
johanmon pushed a commit to johanmon/julia that referenced this issue Jul 5, 2021
This error code does not exist on Windows, so any code that relied on
this was broken (would fail this test) on that platform already. In most
cases, it was actually a serious error too, such as `cp -v` or `tar -v`,
which will indeed fail midway and give corrupt results if you do not read
their output to completion!

Reverts JuliaLang#1469, in essence
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests

2 participants