Re: Strange parameter visibility

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Thu, 29 Sep 2016 14:28:21 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Sep 29,  6:03pm, Peter Stephenson wrote:
> } Subject: Re: Strange parameter visibility
> } % unset x
> } % : ${x:=2} | echo $x
> } 2
> } 
> } In this case, we don't know at the point where we start the pipeline
> } whether we're going to be in the current shell or not.
> 
> Hrm.  But:
> 
> % y=3 : ${z:=2} | echo $y $z
> 
> % 
> 
> Why do we know *there* that we should fork before expanding ${z:=2},
> when we don't know in the absence of the y=3 prefix?  Or is something
> completely different happening, e.g., save_params() / restore_params()
> that I was looking at before?

That LHS turns up in execpline2() as WC_ASSIGN, which I've just changed
(if you're using the change I put in).

I wonder if that means there are cases where the change is problematic
--- I hadn't realised this also covered assignments before running a
command.  Given your experience elsewhere, you might find this makes
pipestatus worse if you test it on relevant shell code, for example.

> Under what circumstances is it possible to do anything useful with a
> pipe without forking the left side?

The interesting thing --- which goes back into history and I've never
properly got my head round --- is how the fork at that point interacts
with the fork inside execcmd().  If it's a simple command being run
you'd have thought we either fork there or above, and not both, but I'm
not sure about that (and I'll need to check if that just got changed
with WC_ASSIGN with an external command --- if there's a double fork
for an external command I'll need to back that off, or think about
introducing WC_ASSIGN_ONLY).

One clue is the "output" parameter passed into execccmd() that says if
we're talking to a pipe.  That's used in the fork decision with the big
comment around exec.c line 3166: if we're executing a builtin or a shell
function and we're outputting to a pipe, we fork there.  I think the reason
we *don't* fork there for is_cursh is exacxtly because of that test in
execpline2() --- we knew at that point it was shell builtin code, so
didn't need to defer the decision.  We needed to defer the decision if
we hadn't analysed the command to see if it was a builtin or not.  If
it's not a builtin or current shell structure of some sort, we always
fork down in execcmd() (unless exec'ing).

Another ingredient here is the position of prefork(), the clue being in
the name, which is where the ${z:=2} assignment takes place.

If you're not confused, I haven't correctly transferred all the
limited information I do have...

pws