Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu (Pete Goodeve)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Pipe syntax... I think I'd better think it out again...
Message-ID: <1990Nov24.073600.10802@agate.berkeley.edu>
Date: 24 Nov 90 07:36:00 GMT
References: <1990Nov18.090654.24747@agate.berkeley.edu> <1990Nov19.031449.25071@ux1.cso.uiuc.edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: University of California, Berkeley
Lines: 45


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!)

> [.....]
> 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 <PIPE:AA
> 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.)

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 --