Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 08 Aug 2019:
>
> 2019-08-08 10:21:14 +0100, Geoff Clare:
> [...]
> > A bigger issue with bg, in shells that treat each pipeline in a
> > foreground AND-OR list as a separate job, is that if one of those jobs
> > is stopped and then placed in the background, what happens to the
> > remainder of the AND-OR list? For example:
> >
> > sleep 10 && echo foo
> [...]
>
> Again, "each pipeline in a foreground AND-OR list" is a wrong
> (incomplete) way to look at it.
>
[...]
>
> h() { i; j; }
> { a | b; for i in 1 2; do c "$i"; done; { d; e; } | f; } && { g; h; }
>
> (that is, the same without the & in the end).
>
> In shells other that zsh, that does not run a job for those two
> pipelines on either side of the &&, but a job for each of:
>
> - a | b
> - c 1
> - c 2
> - { d; e; } | f
>
> And if the first {...;} succeeds:
>
> - g
> - i
> - j
Did you mean to say "In shells that don't treat the whole AND-OR list
as one job, although not in zsh, ..."?
I tested a complex (although not as complex as yours) AND-OR list in
ksh93 and it treated the whole thing as one job:
$ { sleep 3 | sleep 4; sleep 1 | sleep 2; } && { sleep 5; sleep 6; }
^Z[1] + Stopped { sleep 3 | sleep 4; sleep 1 | sleep 2; } && {
sleep 5; sleep 6; }
$ jobs
[1] + Stopped { sleep 3 | sleep 4; sleep 1 | sleep 2; } && {
sleep 5; sleep 6; }
$ fg
{ sleep 3 | sleep 4; sleep 1 | sleep 2; } && { sleep 5; sleep 6; }
For bash and the shells that behave like it, the added complexity doesn't
change my point (except perhaps to strengthen it).
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
