🚀 go-pugleaf

From: gnu@hoptoad.UUCP (John Gilmore)

In article <8128@ut-sally.UUCP>, akre@cuuxb.uucp (Mike Akre) writes:
> Find knows how to not cross mount points in System V Release 3.0 and later.
> It has a new option "-mount" that will restrict find's searching to the
> filesystem containing the directory specified.

SunOS 3.2 has a similar option, called "-xdev"; it says not to cross into
a different device than the one on which the filename argument resides.
As far as I can see, the two are the same.

Ted Nolan (ted@usceast.uucp) posted diffs to Unix tar to add a "T"
option to read filenames from standard input.  However, his changes
only worked for creating archives, not for reading from them.  His
changes were in net.sources posted 17 July 1984, as an "ed" script
for editing 4.2BSD tar.c.  I can provide copies if anybody wants 'em.
I also generated a context diff from this and can provide that.

It is true that my PD tar can read a list of filenames from standard
input, for both creating and reading archives.  It can also deal with a
large list of names to extract even on a small memory system, by giving
it another option letter indicating that the list on stdin is sorted to
match the tape.

I think that the argument boils down to:

*	Neither tar nor cpio is perfect for what we want.

*	People like cpio's user interface better.

*	Tar's format on the tape is more portable.

As a standards effort, we can't just create a new "portable" format
which is not portable to all the old Unix systems.  If we claim the
standard format is "cpio" or "tar" format, the old cpio or tar should
be able to read it.  All the suggestions for improving cpio format (Andy
Tannenbaum's are a good example) ignore interchange with older systems.
If we decide on a format which neither tar nor cpio, as they now stand, 
can read, let's invent a new name for the format and the command (posio,
for portable standard I/O?  That sounds too much like stdio though. 
Posar?).

Personally I think what matters most is the interchange format, not the
user interface; this is why I favor tar.  The user or system implementer
can always provide a better, or additional, user interface but they
are stuck with the interchange format.

As I recall, the draft I saw standardized the interchange format but
specifically did not standardize the command used to generate that
format.  How would people feel about a compromise wherein a new option
added to "cpio" would cause it to generate or read POSIX interchange tapes,
which might happen to have a format compatible with V7 tar?  Vendors
could make this option the default if desired, requiring the user to
specify an option to write binary or ascii cpio tapes.  When reading,
it could figure out the format of a tape without user intervention.

Volume-Number: Volume 11, Number 36