Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Fish shell sends unexpected SIGPIPE to running processes #1926
When running some commands, the shell kills my jobs before they complete.
For instance, I'm trying to run that command:
The first command (lld) try to link the input object, print some internal status to stdout and then write the produced object to disk.
It is perfectly valid and expected that FileCheck terminates before lld as it may be done looking for string in the output before lld is done writing the result to disk. When running that command in any shell (bash, tcsh, …) everything works fine, but when running it in fish, at some arbitrary point, lld receives a SIGPIPE signal that cause termination resulting in incomplete execution: the produced file is not valid (or not created at all).
Note: The function responsible to kill the process is in proc.cpp: kill(prev->pid,SIGPIPE);
I think that perhaps fish is just a little more eager about killing the process, but is behaving basically the same as other shells.
For example, if I run:
y y y y
Therefore if a change was going to be made, we would have to decide exactly what it should be.
On investigation, there is one difference between bash and fish (not sure if this is a "bug", but it is a measurable difference.
Given the following script (slow_print.sh)
Then the command
What I don't know is, should this be counted as a bug, or a feature :)
(sorry for repeated comments).
I can now sum this issue up compactly:
bash and zsh allow naturally occurring SIGPIPEs to cause piped together processes to exit, so given
fish on the other hand will eagerly kill
If this is a feature, I would be curious to know what is the motivation to kill the parent process immediately when the child process exit and not when the parent try to write to the close pipe.
As some application expect the bash behavior but no application expect the fish one, I consider it as a bug more than a feature. In my case,
The command works perfectly with any shell but fish.
Git blame shows that this behavior was already in place when the first git commit, 149594f, was made on 2005-09-20 and the code was still written in C. I don't think there is any question that this behavior is wrong. It appears to be a misguided effort to not "waste" time waiting for the left hand side of a pipe to notice that the right hand side has terminated. But that is just plain wrong since fish has no idea what that process might be doing and can not assume that preemptively killing it is safe.
The fix is trivial (see
If I do so the resulting shell passes all unit tests and works fine for me. The question is whether we dare to change it in a minor release. It's certainly possible people will notice the change in behavior; specifically, pipelines not completing as quickly. But I don't see how that could cause any problems or itself be construed a bug. So I think we should change it in the next minor release.