Dual BSD/S5 UNIXES

[Guy Harris]

> 	A - S5 and BSD4.2 seperately
> 	B - A superset
> 	C - A Dual port
> 
> Choice B was the track that GOULD had first taken (with the help of
> the BRL emulator). This caused a lot of flack from system adminstrators.
> Some commands behaved in fashion that was neither pure
> BDS 4.2 or pure System V.
> 
> Choice C is Gould's current strategy. There is a /usr/bin and a /usr/5bin
> a /usr/lib and a /usr/5lib a sv and a bsd command, etc.
> 
> Having worked on  Pyramids, Goulds and single SV5 and BSD4.2
> machines, I favour choice C. Choice A is unweildy. Choice B is 98% ok,
> but those 2% of commands that behave funny cause real headaches.

At this point, it seems the term "dual port" covers a multitude of
implementations; the definition, I guess, is "any system that has two
versions of 'tr'" or something like that.  The question is whether you have
duplicate versions of *every* command, or just the ones where they are
incompatibly different, not just where one can be made into a superset of
the other by adding the (possibly null) set of additional features from the
other.  For instance, keeping two versions of "fgrep" is just dumb; the main
difference between them is that the 4.2BSD version derives from the version
supplied with an addendum to V7, and thus has a bug fix that the S5 version,
which seems to derive either from the original V7 version or a later version
that still predated the V7 addendum, does not.

The same question applies to things like "stat"; if you read the S5 manual
page, the 4.2BSD version of "stat" is 100% compatible with it, so there's no
good reason to revive the 4.1BSD "stat" call and use it in the S5
environment.  There are some S5 programs that incorrectly assume that
"st_atime" and "st_mtime" are contiguous (this is NOWHERE stated or implied
in the S5 manual page, and in fact the S5 "lint" library entry and manual
page entry for "utime" make pains to ensure that you do NOT pass "&st_atime"
to "utime"), but those programs ("cpio", "pack", and "file") should be fixed.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)