🚀 go-pugleaf

In article <1990Nov10.082242.22949@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes:
>
>In  <1990Nov8.101107.5884@zorch.SF-Bay.ORG>,
>Kent Paul Dolan (xanthian@zorch.SF-Bay.ORG) writes:

	[ an interesting idea which I (personally) think looks a bit
	  ugly and daunting to type from the keyboard ..]

>Hmmm.  What an interesting idea...  In fact it gets more intriguing as I
>think on it.  "Fan out pipes" are something that even unix can't do, as
>far as I can see.  (You can 'tee' to a pipe and a file, but not to two
>parallel pipes, can you?)  And a convenient way of "broadcasting" data to a
>number of processes is something that I've had on my mind for a long, long
>time.

Unix has the capability of doing this - all the OS facilities are
there it's just that it's hard to represent it in a linear line of
text.  Since Unix commands (under /bin/{,c,k}sh) are a linear line
of text this is a problem.  In fact, I vaguely remember seeing a
multi-way `tee' program come across some sources group once.

Another problem is -- where might this be used?  As I said above,
the notation you're suggesting is a bit ugly (to my eye).  It's
not the sort of command I'd be typing in off the top of my head
and, besides, I've lived on Unix for years with just linear pipes.
The few times where it might've been nice to have tree-structures
of piped-together processes has always been in a shell script & it
was pretty easy to use temp files of my own & delete them when done.

For an ad-hoc creation of tree-structured piles of processes it
seemed you'd want some sort of graphical shell in which you'd have
process names and pipe symbols that you could drag around & connect
up & play around with.

cmd1 | (
    tee /tmp/some-file; some-other-command </tmp/some-file; rm /tmp/some-file 
	) | cmd2

Hmm.. that just came to me, and is perfectly reasonable in Unix
shell-ese.  The string of commands under "some-other-command" would
not even start until the "tee" process finishes, then any output
it makes would go into `cmd2', _following_ the output of `tee'.
Also if you iterate on the () (in Unix shell-ese that starts up a
subprocess executing the command string within ()'s) you can create
a fairly bizarre nesting of processes.  Using `&' and `>' would
send some-other-command off into the background so that `cmd2' can
finish without having to wait for some-other-command to finish.

But toss a few inline awk scripts into that pipeline and it quickly
becomes un{read,maintain}able.

>             PIPE cmda args >-{1,2}  +
>             cmdb args >-{1,2,3}     +
>             -<1 cmdc args >-2       +
>             -<2 cmdd args >-4       +
>             -<3 cmde args >-1       +
>             -<4 cmdf args > result
>
>This isn't much worse (to my eye!) in appearance that the other,

Well.. I guess there's just no pleasing some people.  If I'm reading
this right you want the input of cmdd to be some combination of
the outputs of cmda, cmdb and cmdc.  If each of those are executing
concurrently how do you avoid mixing the outputs?  If you make sure
the outputs aren't mixed, how do you specify the order that cmdd see's.
Would it be in the order specified in the command, random, or what?


ohwell.. so long as unix-ese-speaking shell's are available then
I'll be happy ;-)..  (And, no, I didn't "grow up" on Unix .. I've
used many many other kinds of systems .. I find the notation in
Unix shell script-ese (Bourne or Korn shell.. I *emphatically*
don't write programs with csh) to be very convenient & powerful.)



-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Use the force Wes!