Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!munnari.oz.au!bruce!labtam!eyrie!phoenix!proff
From: proff@phoenix.pub.uu.oz.au (Frederick Solidus)
Newsgroups: comp.sys.amiga.tech
Subject: Re: PIPEing from ser:
Message-ID: <1990Nov21.160335.14624@phoenix.pub.uu.oz.au>
Date: 21 Nov 90 16:03:35 GMT
References: <6997@sugar.hackercorp.com> <1990Nov7.235254.13959@opusc.csd.scarolina.edu> <7025@sugar.hackercorp.com> <1990Nov12.101531.19828@agate.berkeley.edu> <1990Nov16.104712.20944@phoenix.pub.uu.oz.au> <phil.658973999@adam.adelaide.edu.au>
Organization: Phoenix ComSystem. Public UNIX Melbourne Australia.
Lines: 36

In <phil.658973999@adam.adelaide.edu.au> phil@adam.adelaide.edu.au (Phil Kernick) writes:

>proff@phoenix.pub.uu.oz.au (Frederick Solidus) writes:

>>I know the 1.3.2 PIPE: device overflows if asked to preform something like
>>downloading a 10k+ plus file to pipe: as one "lharc x pipe:"'s but does
>>the dpipe: device on dnet have this problem?

>What *exactly* do you mean by "overflows"?

>If you mean that your command seems to hang when you type it, it means that
>the pipe: internal buffer is full.  This buffer is 4k long (it says so in
>the 1.3 docs).

>Try the following:

>1> newcli
>1> copy fubar.lzh pipe:l.lzh

>[ swap window ]

>2> lharc x pipe:l

>Disclamier:  I have not tried this but it should work.  The problem may be
>that lharc expects a .lzh suffix?

>Hope this helps,
>Phil

No, that is nope the problem (execpt ARP tends to deal with non-filing devices
poorly). This sort of overflow only occurs with downloading from a terminal
program to pipe:

Proff/The Force

Don't trust the mail header, use  munnari.oz!labtam!eyrie!phoenix!proff