1003.2 Command Groups && Are we standardizing Unix or not?

[Moderator, John Quarterman]

From: hoptoad.UUCP!gnu at cgl.ucsf.edu (John Gilmore)
Date: Sun, 11 Jan 87 02:51:14 PST

> From: gwyn at brl.arpa (Douglas A. Gwyn)
> >From: hoptoad!gnu at lll-crg.arpa (John Gilmore)
> >...  Is it going to be possible to sell a
> >POSIX system without UUCP?  Ditto for "mail"...
> 
> I don't see why these should be mandated when many sites use
> superior facilities in their place.  Ditto for the spooler.

There are several points here, and I didn't make things very clear.

(1)  A Posix system should be able to talk *over the phone* with a Unix
UUCP site.  Why should a Posix user be reduced to public domain kermits and
things for communication, when we all know we are standardizing Unix, and
uucp comes with every Unix ever released by AT&T or Berserkeley?

(2)  Applications should be able to use a standard interface to send
mail.  It should always be possible for a shell script or program to
invoke "/bin/mail" with an addressee as argument and a message on
standard input.  No matter what the protocol used to move or read the
mail.  SysV and Sun do this right; BSD Unix messes it up a bit with the
Apparently-To: headers, producing mail that violates RFC822 if you
invoke it this way.  But it works well enough everywhere; make it standard.

(3)  The same is true of a spooler.  You can provide a fancy spooler,
but please let dumb programs invoke it by the same old name as long as
they only depend on the dumb options, e.g. "lpr" and "lpr -p".

(4)  This would be useful for file transfers too, but there is no clear
standard (uucp, kermit, ftp, rcp, tftp, plus whatever comes with 3Bnet)
and the different methods disagree on whether it happens immediately or
is queued, whether return status is available, whether you have to
specify text, binary or other file attributes, etc.  If we require that
Posix talk over the phone to uucp, we might as well require that the uucp
command syntax be usable to invoke those transfers.
 
> From: gwyn at brl.arpa (Douglas A. Gwyn)
> The standard should not be weakened unduly to permit existing
> inadequate facilities to be advertised as already conforming!

This last statement is indicative of a severe miscommunication
somewhere.  I thought we were standardizing *UNIX*.  U. N. I. X.  Not
somebody's great idea of what Unix should be after you fix the
"inadequate facilities", but what it already is.  Right now the de
facto standard, that is, what commercial applications or mod.sources
postings can reasonably assume, is roughly V7 with a few mods (the
Berkeley directory access library, for example).  Why should we write
up a document that claims differently and call it a standard?  The
point is to limit the variation.  We have failed if we create yet another
variant that's not a subset of most of the existing ones.

I'm not interested in old vendors' being able to advertise their
systems as "already conforming".  (I'm working on the GNU project which
will write it all from scratch anyway.)  What I *am* interested in is
portability of applications.  Talked to Mike Gallaher about Unix
portability?  He's been porting Emacs to Gosling knows how many
systems.  Talked to RMS, or the Alis or Ingres or Common Lisp or
AutoCad people?  What does mdqs depend upon?
What do they need to be able to depend upon?

If today's version of netnews would not run unchanged on Posix, as it
runs unchanged on dozens of variants of Unix, I say Posix is not meeting
its goals.  (I don't know whether it would run under Posix, or not.)

:-) I can see it now, it will take Guy Harris another 2 years to
produce "the amazing Veg-a-Sun-Unix, it slices, it dices, it splits hairs,
it runs BSD and SYSV and if you order today you'll even get the
terrific unified separate but equal Posix variation compatability
library!"  :-) NO thanks...


Volume-Number: Volume 9, Number 19