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: <6863@ut-sally.UUCP>
Date: Wed, 14-Jan-87 21:07:28 EST
Article-I.D.: ut-sally.6863
Posted: Wed Jan 14 21:07:28 1987
Date-Received: Thu, 15-Jan-87 04:26:48 EST
References: <6710@ut-sally.UUCP>, <6783@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 60
Approved: jsq@sally.utexas.edu

From: pyramid!utzoo!henry (Henry Spencer)
Date: Fri, 9 Jan 87 21:08:38 CST

> A general suggestion on the command groups:  provide just two sets.  A
> mandatory group and a group that "if you have this function, you must
> provide it under this name", a la X3.64.  No requirement that every
> command in the optional group must be there if any of them are...

There is something to be said for this.  Unfortunately, there is also
something to be said against it.  The problem is analogous to the one
with X3.64, to wit that there is no "standard" beyond the basic one,
or rather there are far too many, specifically 2**number_of_options.
The result is that each system becomes unique, and the specification
of what a particular application requires is no longer "P1003.2 with the
optional command set" but "P1003.2 with A, B, C, D, E, F, G with the -x
and -q options, H, I, and Q".  What this means in practice is that nobody
bothers specifying exactly what his application needs, and the only way
to find out whether it will work on your system is to try it (remembering,
of course, to try out all features with all combinations of input data and
all possible environments!).  It's better than no standard at all, but
much less useful than a group that is a single option.

I would be interested to know why John thinks this is desirable.  The
occasional situation of X being hard to do under system Y can be handled
outside the standard ("we do all of P1003.2 except grep" :-)).

> I don't understand the philosophy that includes "cc" but excludes "as" and
> is not sure about "lint" and "m4" and "strip".  I see a lot of makefiles
> assuming all of these...

I would guess that the exclusion of "as" is because its behavior is utterly
unportable even though its concept is not.  Why would a makefile for a
fully portable program invoke "as", without at least making it conditional
on a specific type of machine?  It's not clear to me that there is any
portable operation that "as" can perform.  (Note that it is possible and
plausible to have a compiler which does not generate assembler as an
intermediate stage, so "assembling the results of a partial compile" is
not a good answer.)

> I suggest that "cpio" be excluded.  Maybe they'll stop distributing
> System V on byte-order-dependent cpio tapes if it becomes non-standard.

Agreed.  P1003.1 has already defined a standard interchange format, and it's
not cpio (it is, in fact, a somewhat extended tar).

> There should be some way for shell scripts to invoke a pager...

If this is done (on the whole I like the idea), there should also be a way
for the shell script to determine that it does not need to do so.  Many
people feel that this function is best done in the terminal driver.  (My
intent is not to re-open this debate in an inappropriate forum, but to
point out that this is a subject on which there is no consensus and hence
it would be better for 1003.2 not to take sides.)  Some existing programs
honor the convention that a null (as opposed to missing) PAGER environment
variable means "don't worry about it", but some do not.

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

Volume-Number: Volume 9, Number 18