command substitutions (for some reason known as "subshells" in this part of the code)

The reason being that it's not just command substitutions - it's also e.g. the prompt functions or completions.

That means after this, complete -c something -a '(read -l something)' will actually read when completing something . That doesn't seem useful, but it also doesn't seem harmful, in an "if you want to shoot yourself in the foot" kind of way. Similarly, now the prompt could read stuff, where previously most likely whatever would try to read would get SIGTTOU and stop, leaving stray processes all over the place.

echo (cat) (which would print a newline and leave a stopped cat)

Do you mean that you leave behind a cat waiting on stdin ? Could this cat interact with the standard input after the end of the echo command ?

Do you mean that you leave behind a cat waiting on stdin ?

Not quite. The cat has received a signal (SIGTTIN or SIGTTOU) because it tried to read from or write to a terminal that it did not have control over. Now, a process could react to these signals and do something different, but the default action is to stop (as if it received SIGSTOP), which is also what cat specifically does.

Could this cat interact with the standard input after the end of the echo command ?

No, because we never give it control of the terminal. We could theoretically give it up later, but that would make $anycommand (cat) meaningless. What this does instead is give it control when we start it.

May I however add that it does not solve the issue with pipes, for example with sudo netstat -tnpa | grep sshd. Should I file a different issue ?

May I however add that it does not solve the issue with pipes, for example with sudo netstat -tnpa | grep sshd. Should I file a different issue ?

No, that's #206.

Edit: Note that this exposes the actual issue there - we don't redirect properly, the command ends up connected to the terminal. With this, it'll have permission to read/write. Without this, it'd get SIGTTIN/SIGTTOU, be stopped and hang around.

echo (cat) (which would print a newline and leave a stopped cat)

FYI, yes it does although that isn't immediately obvious since you are returned to your interactive shell. And you have to run the jobs command or something like ps waux | grep cat to notice those stopped jobs.

This simple fix seems almost too good to be correct. So it is going to need some testing and analysis before being merged. Having said that I am cautiously optimistic this is correct or at least more correct than the existing behavior based on my limited testing.

This simple fix seems almost too good to be correct.

Yes, it does. Though it also makes a certain degree of sense - this code explicitly stops any "subshell" from using the terminal, so removing it should allow it to.

Having said that I am cautiously optimistic this is correct or at least more correct than the existing behavior based on my limited testing.

Yes, "more correct" being the thing to shoot for. Maybe there is a case where something shouldn't receive access to the terminal, but that case should be handled specially then. Also it appears less common than command substitutions, given that I haven't found it so far.

I can't think of how this change could cause problems absent bugs elsewhere in the code and I haven't observed any problems. Too, it is important to get more people testing this sooner rather than later. So I've gone ahead and merged it.

I just want to say THANK YOU for fixing this. This was one of my biggest complaints about fish. I think now I might be sold for life.

Man, four hours of troubleshooting trying to figure out what was causing my issue, looks like this was it! Thank you for the fix!