🚀 go-pugleaf

In article <128@ryesone.UUCP> mason@ryesone.UUCP (Dave Mason) writes:
>We have a standard university license for Unix, have the source tape,
>and then were given/sold an IBM Series/1 Interactive Executive, a basically
>SysV post with Berkley tty handlers (and completely mangled manuals) which
>is a binary port.  I want to get some of the sources off our tape, which I
>understood to be in cpio format, but cpio wants nothing to do with it, nor
>does tar.  I have taken a quick look at it with od, and it looks vaguely
>like a cpio format.  Any suggestions?

Remember that there are really two CPIO formats:
	(1) binary headers, therefore machine-dependent format
	(2) ASCII headers, therefore portable format
If your tape is the latter, you need to add the letter "c" to the
list of "cpio" options in order to read it.  If your tape is the
former, it must be read on a machine with similar binary architecture
(unless you want to hack up a special version of "cpio") without using
the "c" option.

One final note: really old versions of CPIO did not support ASCII
headers.

> Remember that there are really two CPIO formats:
> 	(1) binary headers, therefore machine-dependent format
> 	(2) ASCII headers, therefore portable format
> If your tape is the latter, you need to add the letter "c" to the
> list of "cpio" options in order to read it.  If your tape is the
> former, it must be read on a machine with similar binary architecture
> (unless you want to hack up a special version of "cpio") without using
> the "c" option.

What really annoys is that this requirement for a machine with a similar
binary architecture is really totally unnecessary!  All the "cpio" control
information consists either of 1) 16-bit numbers (even the 32-bit numbers
are made out of two 16-bit pieces) or 2) ASCII strings.  The latter are
totally unaffected by the byte-order of the machine (they are affected by
stupidity in the tape controller, if it doesn't write out character strings
in memory to consecutive frames on the tape, but to fix that you have to run
the tape through "dd" with "conv=swab" and pipe that to "cpio" - the
byte-swapping options of the System V "cpio" don't swap the bytes of *all*
blocks, just blocks of file data or ASCII filename strings, i.e. exactly
those bytes which should *not* be swapped), and the former can all be fixed
by swapping their two bytes.  "cpio" need merely look at the magic number,
and if it looks like the normal "cpio" magic number with its bytes swapped,
set a flag which tells it to swap the bytes of "cpio" headers (and nothing
else).

Yes, it works.  I built such a version and tried reading a tape, which was
made on a VAX, on a Sun.

Is anybody from the USDL listening?  If so, put this change in.  (And, while
you're at it, get rid of those idiotic error messages which print the
*decimal value* of "errno"!  NOBODY wants to see that number.  They want to
see something meaningful, like, say, "sys_errlist[errno]", assuming that
element exists.)

> One final note: really old versions of CPIO did not support ASCII
> headers.

Specifically, System III and earlier.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.arpa	(yes, really)