Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!lrg7030 From: lrg7030@uxa.cso.uiuc.edu (Loren Rittle) Newsgroups: comp.sys.amiga.tech Subject: Re: Pipe syntax... I think I'd better think it out again... Message-ID: <1990Nov26.103402.2714@ux1.cso.uiuc.edu> Date: 26 Nov 90 10:34:02 GMT References: <1990Nov18.090654.24747@agate.berkeley.edu> <1990Nov19.031449.25071@ux1.cso.uiuc.edu> <1990Nov24.073600.10802@agate.berkeley.edu> Sender: news@ux1.cso.uiuc.edu (News) Organization: University of Illinois at Urbana Lines: 93 Pete Goodeve writes on (Nov 24, 1990): >In <1990Nov19.031449.25071@ux1.cso.uiuc.edu> (19 Nov), >Loren Rittle (lrg7030@uxa.cso.uiuc.edu) writes: >> >> While I do agree that many standard commands as shipped from Commodore >> (under 1.3 and before) don't ``pipe'' well, all the GNU unix tools do. >> All the so called buggy ARP commands that I use everyday with no >> problem support reading from standard-in and writing to standard-out. > >Yes, agreed, but I think what I was trying to put across is that the >`filter' model isn't appropriate for a lot of operations you can otherwise >do with pipes. For example the other day I wanted to check the changes >I'd made in a file I was editing before I saved it, so I simply dumped it >out to a pipe and ran `dif' on that and the original. (Only one of the >inputs was a pipe, so in theory I suppose it could have been stdin, but >even unix `diff' doesn't handle that possibility!) OK, I see what point you are making now, I concur with you about this. I just want it to be clear that there is nothing wrong with AmigaOS which inhibits the use of `filters' and `pipes' (unnamed unix style!). I do agree that the named pipe mechanism is quite powerful, but I want unnamed pipes also (I currently have them and use them quite often on my Amiga). No good reason why we can't have both, right? With the WShell, I get quite reliable unnamed pipes. I, at least, would only want an extension to this, I would not be willing to give up my easy to use unnamed pipes for what is turning into a big mess (Another's observation [yours perhaps] after looking at the discussion, so take no offense, none meant)! Let's have both. >> [.....] >> By the way, many commands that won't handle piping won't handle >> any better under your new idea. The MORE command as distributed >> by Commodore is a prime example: >> >> MORE > and >> MORE PIPE:AA >> >> using any pipe device you care to use causes the MORE command to >> get quite upset, at least under the 1.3 version of MORE. [.....] >> LESS, another non-standard standard command is the only pager >> that I have found that supports pipeing the way it should. > >How very odd. On my system, MORE works reasonably happily with a pipe >(and I know Carolyn intended it to...) -- except that it double-spaces >for some reason. (It does that also if you give it input from a console >window.) LESS (the version I have. anyhow), on the other hand, objects >that it "Can't accept input from a terminal". (Whereas you CAN pipe to >less on unix -- it just won't backtrack past its current buffer.) I guess the point I tried to make is that if all the standard commands and commands written by others don't work as filter (as you say) because they don't like reading from or writing to pipes then they will not work with the new ideas for multiple named pipes. I still think that this is a correct statement, but I would also argure that most commands (maybe not Commodore's 1.x commands) that can, support piping. So the whole point is moot in my mind. BTW, The double-space problem is the same one I encountered. This is not a feature! It's a bug! I was just about to type, ``Ahh, the reason your version of LESS does not support piping is that you are most likely using version 1.3 from later Fish disks,'' but then I checked my latest version of Less v2.0ljr and guess what --- It does not work with the pipe: device! But it does work just fine with WSH's pip: device! I would be willing to bet that pipe: files look like interactive streams, as this is the only check LESS does on a file before allowing it to be viewed. (BTW, this is the same check that is done under the UNIX version of LESS! Right or wrong this is the restraint LESS puts on a file, it sounds OK to me.) If this is the case, then it is the PIPE: device that has a bug, not the LESS program. I will look into this problem and report back. >Could it be, I wonder, that your "Bug-Free" ARP system is not quite so..? >(:-)) (:-)) Actually, I've run into little snags of this kind every time >I've tried ARP -- or tried to use scripts that run fine on my system >on somebody else's with ARP installed -- so that is why it is NOT on mine... >[but that's another thread, isn't it.] > > -- Pete -- [I assume that you are refering to the MORE problems...] Humm, (:-) :-)) guess not as I have looked into the piping problems quite extensively with and without ARP... Loren J. Rittle [Free plug: my version of LESS only opens a window if started from the WorkBench, else it will use the console window from which it was started from. Fully supports unnamed piping with the PIP: device under the WShell. (And as soon as I get a chance to look into the problems involved, named piping from the PIPE: device, I currently think that the fix will involve a kludge, I hate kludges...)]