Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: tar xf - (was Re: Microport Unix V/AT and 9600 baud)
Message-ID: <8896@mimsy.UUCP>
Date: Sat, 3-Oct-87 12:40:42 EDT
Article-I.D.: mimsy.8896
Posted: Sat Oct  3 12:40:42 1987
Date-Received: Sun, 4-Oct-87 06:49:08 EDT
References: <1198@dasys1.UUCP> <207@eurifb.UUCP> <105@suprt.UUCP> <4764@ncoast.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 14

In article <4764@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes:
>... I've had problems with some systems reading from a zcat | tar xf -
>pipeline, which goes away if I uncompress the input file and say tar
>xf filename.  I infer that the "blocksize" on a pipe is widely variable,
>at least with zcat on the other end, ....

The block size does indeed depend on the program behind the pipe.
If you have a 4.2BSD-based tar, `zcat | tar xBf -' solves the problem;
4.3BSD's tar automatically asserts `B'lock-buffer with `f'ile `-'.

On other systems, `zcat | cat | tar xf -' may work.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris