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: <6786@ut-sally.UUCP>
Date: Wed, 7-Jan-87 18:54:31 EST
Article-I.D.: ut-sally.6786
Posted: Wed Jan  7 18:54:31 1987
Date-Received: Thu, 8-Jan-87 00:09:20 EST
References: <6710@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 48
Approved: jsq@sally.utexas.edu

From: pyramid!utzoo!henry (Henry Spencer)
Date: Wed, 31 Dec 86 03:36:31 CST

Some specific comments on the placement of various commands:

I do hope that cat's stupid options will not be standardized, although
I fear that is too much to expect since they are increasingly widespread.

I hope the standard version of ls will not include mandatory columnizing
of output depending on whether output is to a terminal or not.

Justification for both the above is that the desirability of these bits
of behavior is a contentious subject with no widespread agreement.

The algorithm for "sum" should be specified completely and portably, so
that one can reliably get the same checksum from the same sequence of
bytes on any 1003.2-conforming system.  This is a conspicuous and painful
lack in current systems.  The checksum preferably should be sensitive
to the order of the bytes, not just their values.  Perhaps a CRC code
would be appropriate, given that its properties are well understood,
fairly good, and fully portable?

Putting "xargs" in the Software Development Environment is bizarre, since
its primary use (in my experience) is to make *applications* robust against
the possibility of extremely long argument lists.  It belongs in the
Execution Environment.  It is not a complex program and public-domain
versions exist, so implementation difficulty is hardly an issue.

"File", currently in the "No Decision Yet" list, is quite important.  One
important and subtle characteristic which badly needs standardizing is that
in some (all?) existing implementations, identifications of files which
appear to be ASCII text end with the word "text".

I would hope that if "nm" is standardized, its output format (if specified)
will be the old V7ish single-column format; at the very least, it is very
important to have a standard option that will produce this form.  The new
multicolumn form found in some System V nm implementations is cute but
makes nm output useless as input to other programs -- an important use of
nm.

Standardization of "pack" is inappropriate, since superior alternatives are
already in widespread service, unless the definition specifies the user
interface but not the compression algorithm.

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

Volume-Number: Volume 9, Number 10