Re: [PATCH] problem with 'ls | less' shell function

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Nov 7, 2022 at 4:44 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> the location of the busy-loop is always
> the same.

I'm sure someone is going to explain to me why the following is wrong.

If we're in the subshell and we just came back from being suspended,
why would we not resume the current job?

What happens with the patch below is that in the right side of the
pipeline, after the new subshell is created upon ^Z, "fg" resumes the
previous foreground job (the earlier job in the right-side brace
construct) and the new subshell remains stopped until that job
finishes, at which point it is resumed and proceeds with the next job
in the braces.

There are still some oddball race conditions.  Depending on exactly
when the ^Z is sent, and particularly after the left-side job has
finished, the resumed right-side can become unkillable again.  But
that doesn't always happen.

diff --git a/Src/exec.c b/Src/exec.c
index c8bcf4ee5..b0f42ae67 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -1899,8 +1899,12 @@ execpline(Estate state, wordcode slcode, int
how, int last1)
                        break;
                    }
                }
-               else if (subsh && jn->stat & STAT_STOPPED)
-                   thisjob = newjob;
+               else if (subsh && jn->stat & STAT_STOPPED) {
+                   if (thisjob == newjob)
+                       makerunning(jn);
+                   else
+                       thisjob = newjob;
+               }
                else
                    break;
            }