Path: utzoo!attcan!uunet!husc6!mailrus!cwjcc!hal!nic.MR.NET!umn-cs!uf!brant
From: brant@uf.msc.umn.edu (Gary Brant)
Newsgroups: comp.sys.amiga
Subject: Re: PIPE device
Keywords: 256 byte lag
Message-ID: <10074@umn-cs.CS.UMN.EDU>
Date: 16 Nov 88 19:11:12 GMT
References: <1056@osupyr.mast.ohio-state.edu>
Sender: news@umn-cs.CS.UMN.EDU
Reply-To: brant@uf.msc.umn.edu (Gary Brant)
Organization: Control Data
Lines: 53

In article <1056@osupyr.mast.ohio-state.edu> vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) writes:
>I tried using the pipe device in the 1.3 package together with the tee
>program from comp.sources.amiga. The `feature' also occurs with tee.rexx.
>
>I have tried the following: Open two CLI's (or shells). In one do any of
>the following:
>   <some program> >Pipe:a  (I started with maple, but that shouldn't matter)
>   copy * to pipe:a
>   tee pipe:a
>In the other window, do
>   tee <pipe:a ram:x
>There is a lag between what is supposed to go into the pipe: and when it
>comes out. The later two options above indicate that the output from the
>pipe comes in 256 byte blocks till end-of-file is reached. But the manual
>says that pipe is transparant. C manuals say that `fopen' is unbuffered.

The choppiness you notice is due to the 256 byte buffer size in tee; it is
much more apparent if you have more than one tee running in the same 
pipeline.  This effect does not appear with the Dillon/Drew shell's
piping mechanism ( prog1 | prog2 ) because temporary ram: files are used
for the pipe.

>[Maple kernal is, I believe, written in Manx C]. I am lost as to what is
>going on. Is there any way to have a tee that spills everything it has
>recieved so far. I really need this to use Maple meaningfully.
>
>Incidentally, in case this is pipe:'s fault, do other pipes behave in a
>similar fashion? I was trying to put off buying WShell, but if it will
>tee properly ...
>
>Also the tee from comp.sources.amiga doesn't seems to handle EOF correctly.
>The tee getting its input from the pipe doesn't know that it has got an
>EOF if the feeder to the pipe is "tee pipe:<name>".

I know, I know; when I submitted this, 1.3 enhancer kits hadn't made it to
Minnesota yet, and so I had not been able to test this with a real pipe ;-)
Manx read apparently returns a zero when the pipe: is empty,
this is also the end-of-file signal.  A new version is nearly ready which
works with pipe:.  If you need something immediately, send me mail & I 
will send you source/uuencoded binary.


>
>Thanks in advance for your help.

You're welcome.


I don't have a .signature...

 -Gary Brant  

ARPA:    brant@uf.msc.umn.edu