🚀 go-pugleaf

In  <MWM.90Nov19143124@raven.relay.pa.dec.com> (19 Nov),
Mike Meyer (mwm@raven.relay.pa.dec.com) writes:
> In article <1990Nov18.090654.24747@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes:
|> [says....
>
|>              run list >IP:xx
|>              search IP:xx Nov
|>   ....doesn't work ]
>
> Hmm - I remember setting up complex pipes that way using Search. Then
> again, I may have been using Ed Pucket's (I think that's it) PIPE:,
> that lets you do a "dir" on them. It's been a while since I did that.

Yup.  Ed's pipes are fine for that, because they are the only ones that
are a true file-system, with Locks and all.  I like his scheme a lot,
and I'd still be using it, except for a couple of things: it's a little
bulky compared to others, and -- like the others -- it BUFFERS!

>    [.....]                               What we need is a syntax
>    to specify the insertion points.  Unlike the unix situation, where direction
>    of dataflow is indicated by sequence on the line, our syntax will have to
>    say whether each pipe-argument is an input or output.
>
> Pete, Unix has had that for _years_. I installed it on the machine
> you're running on now (though I can't guarantee that someone hasn't
> uninstalled it since). Try running ksh, and the syntax:
>
>       grep Nov (ls -l)
>
> should do just what you want.

Heh.  I guess it all depends what'cha mean by "unix" dunnit...  (:-))
It also seems to depend on what you mean by "ksh".  You're right --
the violet version of ksh has this feature (but boy was it hard to find
in the docs) but the one we have available for Suns doesn't, neither
does the one supplied as the standard shell for our new IBM 6000.
And Peter da Silva reported yet ANOTHER ksh (or did he mean sksh?)
syntax using '$' a few messages back.

> I like that way of doing things. The command whose output is going to
> appear in the file name substituted is in the place the name will
> appear. That means you have to look fewer places to find the
> information. When you get multiple input streams going (which I've
> done), it makes it obvious what's going on where. It also deals
> cleanly with embedding commands that embed commands.
>
Yes, it's quite neat, but it still has a strict hieararchical structure.
The sort of schemes we've been tossing around would allow connections
that would be impossible under the ksh method.  Take this hypothetical
[and doubtless dumb] requirement:

        A process P generates a stream of data that is cloned
        and fed in parallel to filter processes Q and R.

        A `diff' process takes the two outputs Q and R, and
        generates a differences stream.
                           ____
               ---- Q --->|    |
               |          |    |
           P-->|          |diff|---> result
               |          |    |
               ---- R --->|____|

This could be done with several of the PIPE command variants people have
suggested, but not with ksh embedding.  Q and R could be embedded as diff
args, but how would you get the output of P to them both?

Of course the PIPE command would also raise the dreaded "loop" spectre,
but although loops could easily cause a lockup, programs CAN be written
to avoid this, so I don't think they should be prohibited -- just warned
against!
                                    -- Pete --