xenix tar query (Haugh at rpp386)

Mon May 2 07:16:14 AEST 1988

(This is not a flame, deserving of it though Mr. Haugh may be)
Mr. Haugh comments on my question:

My responses:

>this must be an april's fools day joke of some kind.  the person (jay libove)
>who posted the original article has made too many mistakes for this to be
>simple stupidity.
No, not stupidity, not an april fools joke. Perfectly accurate and
perfectly reasonable.

>first off, last time i checked there was no 96 tpi 9 sector device.  the
>only 96 tpi device was 15 sectored.
There most certainly is a 96 tpi 9 sector device. What is a 720K
disk? 96 tracks, 9 sectors per track. I not only have it, but use it
all the time. Maybe you have a slightly different Xenix.

>secondly, you have two tar's with the 'c' option in the pipe line.  'c'
>stands for 'create archive', so the input of the second tar is coming from
>the files requested to be archived.  the /dev/rfd096ds9 [sic] device is
>going to be the output device, not standard output as requested with the
>'-' option.
I am quite aware that I am tar'ing, compressing the resulting stream,
and attempting to create a new archive from that. That is exactly
what I want. I want to compress a tarchive as it is created, and use
it as the input to a new tar, which will simply write it out to
multiple tapes for me. (SCO Xenix tar takes the 'k' option to tell it
how large a tape is.) Thus, the '-' as "file to put in the archive"
is a reasonable choice. The problem appears to be that tar dislikes
having standard input as the file to read. It wants to and fails to
stat that file.

>thirdly, assuming jay meant to use 'x' on the second tar, which is the
>only way for two tars in a pipe to work, the input would have been coming
>from compress, which is not in tar format.  you are lucky you only received
>a blocksize message.
I realize now that SCO Xenix tar was not written to allow what I'm
trying to do. I have come up with solutions for the problem,
specifically using something other than tar as the back end to the
pipe, so that the program at the back end simply takes input from
stdin and breaks it up among output tapes.

>i suppose the correct response now would be `RTFM'.
No, not at all. The correct response was "tar wasn't written to
accept stdin as the file to add to an archive". As it happens, there
*are* tars that can do this (Berkeley 4.3 seems to do it fine.)

>- john.
>-- 
> The Beach Bum                          Big "D" Home for Wayward Hackers
> UUCP: ...!ihnp4!killer!rpp386!jfh      jfh at rpp386.uucp :DOMAIN
> "You are in a twisty little maze of UUCP connections, all alike" -- fortune

Jay Libove
Arpa:   Jay.Libove at andrew.cmu.edu	Bitnet: Jay.Libove at drycas.bitnet
UUCP:   ...!{uunet, ucbvax, harvard}!andrew.cmu.edu!Jay.Libove
UUCP:   ...!{pitt | bellcore} !darth!libove!libove