Re: Forking earlier for background code

[Peter Stephenson <p.stephenson@samsung.com>]

I haven't seen any problems with the changes in the list below over the
last week so I'm going to squash the changes and push the result.

pws

On Mon, 23 Apr 2018 09:29:00 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> - Move the early fork even earlier --- the code immediately above it
> was to do with initial examination of command line arguments, and the
> new fork code deals exactly with the cases where we don't need to know
> this.
> 
> - _exit if we forked and were going to return early from
> execcmd_exec().  This shows up particularly in one case with the
> preceding change --- namely assignments.
> 
> - As suggested, remove the previous code in the caller that did the
> fork there if we recognised early this was code to run within the
> shell but in an early part of the pipeline.  This is now redundant.
> (I'm wondering if this special code was there so that things like
> "foo=bar &", which would have polluted the main shell, didn't push
> the original problem beyond the pain barrier --- i.e. it was always
> just a partial workaround.)
> 
> - That change revealed two other things that needed doing.  First, set
> "last1" when we do the early fork so that subsequent code in the
> forked shell knows we are going to exit.  This was revealed by the
> failure of a test that sets an EXIT trap in the left hand side of a
> pipeline. (Existing exit traps are cleared here, but it's possible to
> set a new one and it should go off when the forked shell exits.)
> 
> - Second, Bart's woraround in zsh-wrokers/32171 for a leaked fd needed
> rewriting.  The change is to ensure we always close the pipe fd
> that's not needed in the forked code when we fork (i.e. the input
> side of the pipe on the LHS --- the output side on the RHS was
> simpler and always managed OK).  This seems reasonably transparent so
> I hope it's not going to lead us down a blind alley (Bart added an
> explicit test for the case that was failing).