>The script appears to work if you change each occurance of
>	bs= to	obs=
>which is required due to taking input from a pipe.

That certainly should work (since ibs will then be the default of
512.) This is even more of an issue with DAT or Exabyte tapes, which
actually need particular raw block sizes.

dall> The ibs is redundant because it is the default. The last block
Yes, I just wasn't sure what the default was -- and including it makes
it completely clear what is going on; simply having bs vs. obs
increases the likelihood that someone misreads it as a typo...

>The unix semantics only guarantee that you can read at least one byte
>from a pipe unless it is EOF, in which case you read zero bytes. In
>practice the bsd socket code transfers data in chunks.

good point. (I've seen too much code that assumes that a single write
on one side of the pipe == a single read on the other -- which breaks
as soon as you drop a network connection into the pipe :-)

Since we know the behaviour of all the platforms that matter, leaving
ibs=512 will work in this context. I suppose that changing it to ibs=1
would *guarantee* correct behaviour, at the expense of 512 times more
system call overhead. I'm not recommending that option.

			_Mark_ <eichin@kitten.gen.ma.us>
			The Herd of Kittens
ps. oddly enough, I ran into this exact problem at work 2 weeks ago;
previous product releases were done with raw tar files, but I choose
to gzip everything for a new release -- modified the script to
compensate, and it didn't work, which led me to conduct the above
analysis... It helped to have a rewind-and-reread pass.