Description
POSIX requires that child processes of the shell running a foreground job be assigned a unique process group ID for each pipeline:
For each pipeline in a foreground job, if the pipeline is executed while the list is still a foreground job, the set of processes comprising the pipeline, and any processes descended from it, shall all be in the same process group, unless the shell executes some of the commands in the pipeline in the current shell execution environment and others in a subshell environment; in this case the process group ID of the current shell need not change (or cannot change if it is the session leader), and consequently the process group ID that the other processes all share may differ from the process group ID of the current shell (which means that a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal sent to one of those process groups does not cause the whole pipeline to stop).
However, yash does not currently change the process group of the processes running the body of the process redirection.
This allows such processes to be suspended by typing the suspend key sequence (typically Ctrl-Z) while the command is running, which can result in a deadlock. This unwanted behavior should be fixed, but it would not work to simply follow the POSIX requirements and assign a new process group to the processes.
If we assign a new process group ID to the child process running the process redirection while the shell is running the main command to which the process redirection is applied, typically a shell built-in, in its own process group, then one of the process groups is in the background and at risk of being stopped by SIGTTIN or SIGTTOU. I believe running a single foreground job in multiple process groups is generally a bad idea.
Instead, the child process can be run in the same process group as the shell, but with the SIGTSTP signal being ignored. This way, we can effectively prevent the child from being suspended.