🚀 go-pugleaf

In article <1990Nov18.090654.24747@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes:
   Using named pipes there SHOULD be no problem [pardon my ego -- I'll use
   mine, but any pipe has the same result]:

	       run list >IP:xx
	       search IP:xx Nov

   (Well, it looks good.  Unfortunately if you try it, it doesn't work!
   'SEARCH' won't read anything but a file -- not a PIPE: not a CON:!

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.

   I think we have to abandon the popen/filehandle line of thought.
   The simple key is to have the shell, PIPE command, or whatever, generate
   suitable unique pipe names, and insert them as STANDARD FILENAME STRINGS
   into the command line at user specified places.  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.

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.

I've been trying to get Bill Hawes to add this feature to WShell for a
couple of years now...

	<mike

--