Join GitHub today
Also give subshells the terminal #3922
It turns out the reason
This is likely to need more testing.
Things I've tested so far:
Fixes issue #1362.
The reason being that it's not just command substitutions - it's also e.g. the prompt functions or completions.
That means after this,
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
No, because we never give it control of the terminal. We could theoretically give it up later, but that would make
I took time to test your patch, and this works amazingly well. Please merge as soon as possible :-).
It misunderstood your comment
(which would print a newline and leave a stopped cat) as the new behavior, while it describes the old, buggy behavior.
I tested it and it gives
gmaudoux@klatch ~/p/fish> echo (cat) Hello, World![^D, not rendered] Hello, World! gmaudoux@klatch ~/p/fish>
Simply amazing how this simple fix solves a longstanding pain.
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.
FYI, yes it does although that isn't immediately obvious since you are returned to your interactive shell. And you have to run the
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.
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.
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.