Re: How to misplace an entire pipeline

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Mon, 08 Aug 2011 23:10:32 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Aug 8,  7:27pm, Peter Stephenson wrote:
> } Subject: Re: How to misplace an entire pipeline
> }
> } On Sun, 07 Aug 2011 21:05:07 -0700
> } Bart Schaefer <schaefer@brasslantern.com> wrote:
> } > -	jobtab[thisjob].stat |= STAT_CURSH|STAT_NOPRINT;
> } > +	jobtab[thisjob].stat |= STAT_CURSH;
> } > +	if (!jobtab[thisjob].procs)
> } > +	    jobtab[thisjob].stat |= STAT_NOPRINT;
> } 
> } Looks fairly plausible, anyway.
> 
> Should that be "if (hasprocs(thisjob))" instead, do you think?

To a first approximation, the user isn't directly interested in the aux
procs, but there might still be some knock-on effect.  So until we find
otherwise, I would guess not.
 
> So the following hack does the right thing in the case of piping to
> true where execbuiltin() has returned, but does not do the right thing
> in the case of read.  What needs to be tested in place of (!list_pipe)
> to determine that the tail of the current pipeline is a simple shell
> builtin?

I don't think we've remembered that fact, but it's available (as
is_builtin) in execcmd(), so could be stored before the builtin is
called.  What I don't know about is where to put that information (is it
as simple as using thisjob?), and what might invalidate it.

> In fact even that may not be enough, maybe this needs to know if the
> current job is a simple shell builtin -- it might be blocked on a
> "while read; do ..." or on a "wait" in the middle of a loop, etc.

I suppose it depends on what cases the list_pipe logic would be
triggered.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/