Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-ID: <6860@ut-sally.UUCP>
Date: Wed, 14-Jan-87 20:54:42 EST
Article-I.D.: ut-sally.6860
Posted: Wed Jan 14 20:54:42 1987
Date-Received: Thu, 15-Jan-87 04:21:30 EST
References: <6710@ut-sally.UUCP> <6783@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 30
Approved: jsq@sally.utexas.edu
Summary: Minor comment

From: seismo!hadron!jsdy@sally.utexas.edu (Joseph S. D. Yao)
Date: 10 Jan 87 02:20:18 GMT
Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA

In article <6783@ut-sally.UUCP> hoptoad!gnu@lll-crg.arpa (John Gilmore) writes:
>I suggest that "cpio" be excluded.  Maybe they'll stop distributing
>System V on byte-order-dependent cpio tapes if it becomes non-standard.
>Volume-Number: Volume 9, Number 7

As I understand it, cpio as it currently stands is ASCII (not binary),
in a perfectly understandable format (reasonable byte-by-byte order)
on magnetic tape or byte-oriented file.  The problem is with magtape
interfaces that assume, e.g., little-endian order on a big-endian
machine; and transform
	byte0
	byte1
	byte2
	byte3
to
	byte1 | byte0 | byte3 | byte2
instead of
	byte0 | byte1 | byte2 | byte3
(the classic NUXI problem).
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
			jsdy@hadron.COM (not yet domainised)

Volume-Number: Volume 9, Number 16