Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Piping commands into functions is messed up #1273
This has been partially covered in #206, but the problem is broader than the initial report would suggest, and I'm making a new issue to draw attention to it. (Feel free to close this as a duplicate if that is deemed appropriate.)
The problem is that piping output from a command into things that are either fish functions or fish syntaxes (like
But that's not all. When you pipe the output from a command that doesn't read from stdin into a fish function or syntax, it appears to have a small chance, like 1 in 20 on my machines (sounds great, doesn't it) to lock up fish indefinitely. (This may technically be a separate issue, but may have similar underlying causes, and certainly the surface cause--being piped into fish stuff--is identical.)
Test case for the first issue: First, get your bearings by typing
Test case for the second issue: Copy
I'm assuming the second issue has to do with threading and/or process creation and a race condition of some sort.
See my comments on #206 for more discussion. Other issues mentioning "pipe" may be usefully related.
Still reproduces. In the second case (with the hang), we are reaping the cat process from a signal handler before the waitpid call. I think the reason it requires the begin/end is because that triggers creation of a keepalive process. Without that we'd get ECHILD (no children) back from waitpid; because it exists we have a child and so waitpid hangs.
One fix would be to check for process completion before calling waitpid, but this would still leave a small window. A correct fix would be to block SIGCHLD, check for completion, and then call waitpid. But I think the best fix is to get the waitpid call out of SIGCHLD entirely. Instead, it should either set a flag or write to a pipe, and the main thread alone should call waitpid.