Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!caen!uflorida!haven!decuac!bacchus.pa.dec.com!bacchus!mwm From: mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: Pipe syntax... I think I'd better think it out again... Message-ID: Date: 19 Nov 90 19:31:24 GMT References: <1990Nov18.090654.24747@agate.berkeley.edu> Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 43 In-Reply-To: pete@violet.berkeley.edu's message of 18 Nov 90 09:06:54 GMT 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...