Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: 1003.2 Command Groups
Message-ID: <6710@ut-sally.UUCP>
Date: Tue, 23-Dec-86 12:19:30 EST
Article-I.D.: ut-sally.6710
Posted: Tue Dec 23 12:19:30 1986
Date-Received: Tue, 23-Dec-86 22:37:49 EST
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 71
Approved: j...@sally.utexas.edu
From: seismo!amdahl!...@sally.utexas.edu (Hal Jespersen)
Date: Sun, 14 Dec 86 15:49:17 PST
The following commands were considered by the 1003.2 Working Group
for inclusion in Draft 2.
Strong Support for INCLUSION in "Execution Environment" (mandatory)
ar awk basename cat cd
chgrp chmod chown cmp comm
cp cut date dd diff
dirname echo ed egrep expr
false find getopts grep join
kill ln logname ls mkdir
mkfifo mv od paste pr
pwd rm rmdir sed sh
sleep sort stty sum tar
tee test touch tr true
tty umask uname uniq wait
wc
Strong Support for INCLUSION in "Software Development Environment"
(optional)
admin cc delta get ld
lex make prs rmdel sact
size time unget val what
xargs yacc
Strong Support for EXCLUSION (from either environment)
as banner cal calendar cu
dis mknod news nl red
rsh sdb shl uucp uulog
uuname uupick uustat uuto uux
vi wall write
No Decision Yet
at batch cancel cflow chroot
col cpio cpp crontab csplit
cxref df dircmp du env
ex file id line lint
lorder lp lpstat m4 mail
mailx mesg newgrp nm nohup
pack passwd pcat pg prof
ps spell split strip su
tabs tail tsort unpack who
For those who haven't kept up with the 1003.2 charter, a brief word of
explanation. We have tended to exclude commands that are not useful
when called from application C programs and shell scripts; vi and sdb
are good examples of these.
The total list of commands considered was provided by the X/OPEN Group,
which seemed like a reasonable starting point.
The Working Group solicits your opinions on these groupings and on the
specific commands selected for each.
Hal Jespersen
(408) 746-8288
...{ihnp4|hplabs|seismo|decwrl}!amdahl!hlj
Amdahl Corporation
Mailstop 316
1250 East Arques Avenue
Sunnyvale, CA 94088-3470
Volume-Number: Volume 8, Number 72
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-ID: <6783@ut-sally.UUCP>
Date: Wed, 7-Jan-87 18:35:58 EST
Article-I.D.: ut-sally.6783
Posted: Wed Jan 7 18:35:58 1987
Date-Received: Thu, 8-Jan-87 00:07:45 EST
References: <6710@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 46
Approved: j...@sally.utexas.edu
From: hoptoad!...@lll-crg.arpa (John Gilmore)
Date: Sat, 27 Dec 86 02:57:15 PST
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, or that
if a command exists it must accept all the possible arguments; just a
name we can agree on for each function that a vendor is likely to
provide and a portable shell script is likely to invoke.
What happened to "fgrep"? If "grep" and "egrep" are mandatory, "fgrep"
should be also. (Of course, there should only be one grep, but for
hysterical compatability it should be callable by three names with
slightly different sets of arguments!)
Why are "uucp" and "uux" not considered reasonable things for a shell
script or C program to execute? One of the few things that Unix does
that nobody else does is UUCP. Is it going to be possible to sell a
POSIX system without UUCP? Ditto for "mail"...
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 presume a makefile is close enough to a shell
script to be interesting to the working group.
I suggest that "cpio" be excluded. Maybe they'll stop distributing
System V on byte-order-dependent cpio tapes if it becomes non-standard.
Dump "pack" but put "compress" into the optional section.
There should be some way for shell scripts to invoke a pager. I don't
care which one -- we can all link our system's favorite pager to the name
you choose. Few or no fancy options required on it though; make it generic.
Tail should be in the mandatory set of commands.
df and du are useful, but their output format is not standardized.
Since mostly shellscripts use these to parse their output e.g. to see
if there is enough free space, this must be specified if they are
to be useful.
I can't find "dircmp", "id", and a bunch of others in either V7 or 4.2
so I suspect it is not very portable to assume their existence. Reject...
Volume-Number: Volume 9, Number 7
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@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: j...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!ucbcad!ames!rutgers!husc6!ut-sally!std-unix
From: std-u...@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-ID: <6818@ut-sally.UUCP>
Date: Sat, 10-Jan-87 00:24:37 EST
Article-I.D.: ut-sally.6818
Posted: Sat Jan 10 00:24:37 1987
Date-Received: Sat, 10-Jan-87 19:36:45 EST
References: <6710@ut-sally.UUCP> <6783@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 25
Approved: j...@sally.utexas.edu
From: g...@brl.arpa (Douglas A. Gwyn)
Date: Thu, 8 Jan 87 11:32:58 EST
Organization: Ballistic Research Lab (BRL), APG, MD.
>From: hoptoad!...@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.
>I suggest that "cpio" be excluded. Maybe they'll stop distributing
>System V on byte-order-dependent cpio tapes if it becomes non-standard.
SVR2.0 was distributed on portable-header cpio tapes.
This is also true of the SVR3.0 source distribution.
>I can't find "dircmp", "id", and a bunch of others in either V7 or 4.2
>so I suspect it is not very portable to assume their existence.
You also can't find a decent Bourne shell in those releases.
The standard should not be weakened unduly to permit existing
inadequate facilities to be advertised as already conforming!
Volume-Number: Volume 9, Number 14
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-ID: <6787@ut-sally.UUCP>
Date: Wed, 7-Jan-87 19:00:51 EST
Article-I.D.: ut-sally.6787
Posted: Wed Jan 7 19:00:51 1987
Date-Received: Thu, 8-Jan-87 00:09:51 EST
References: <6710@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 25
Approved: j...@sally.utexas.edu
From: pyramid!utzoo!henry (Henry Spencer)
Date: Wed, 31 Dec 86 03:36:58 CST
Are the commands listed under "Software Development Environment" optional
as individuals or as a block? If the latter, I find it disturbing that it
is proposed to make the presence of SCCS (get, delta, etc.) mandatory to
have a conforming system. SCCS is badly designed and seriously obsolete.
While I realize that there is too much investment in existing SCCS use to
stamp it out any time soon, I suggest that it is an outstandingly poor
candidate for mandatory inclusion in a standard. At least one analogous
system with what is generally agreed to be a vastly superior user interface
and internal design is already in widespread use. Putting SCCS in 1003.2
is not codifying current practice, it is codifying what is increasingly
a relic of the past. This is inappropriate.
If SCCS must be included in 1003.2's Software Development Environment, the
detailed description of the functionality of the commands should be trimmed
down so that it is not necessary to imitate every mistake of SCCS to be
in conformance.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
Volume-Number: Volume 9, Number 11
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@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: j...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups && Are we standardizing Unix or not?
Message-ID: <6881@ut-sally.UUCP>
Date: Sat, 17-Jan-87 19:12:10 EST
Article-I.D.: ut-sally.6881
Posted: Sat Jan 17 19:12:10 1987
Date-Received: Sun, 18-Jan-87 00:49:02 EST
References: <6710@ut-sally.UUCP> <6783@ut-sally.UUCP> <6818@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 74
Approved: j...@sally.utexas.edu
From: hoptoad.UUCP!...@cgl.ucsf.edu (John Gilmore)
Date: Sun, 11 Jan 87 02:51:14 PST
> From: g...@brl.arpa (Douglas A. Gwyn)
> >From: hoptoad!...@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: g...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: tail in 1003.2 Commands
Message-ID: <6882@ut-sally.UUCP>
Date: Sat, 17-Jan-87 19:20:19 EST
Article-I.D.: ut-sally.6882
Posted: Sat Jan 17 19:20:19 1987
Date-Received: Sun, 18-Jan-87 00:49:30 EST
References: <6710@ut-sally.UUCP> <6783@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 28
Approved: j...@sally.utexas.edu
Summary: tail(1) reconsidered
From: colo...@sunybcs.UUCP (Col. G. L. Sicherman)
Date: 12 Jan 87 15:18:10 GMT
Organization: Jack of Clubs Precision Instruments
> From: hoptoad!...@lll-crg.arpa (John Gilmore)
> Date: Sat, 27 Dec 86 02:57:15 PST
>
> ... Tail should be in the mandatory set of commands.
I know that tail is in BSD. Is it a Berkeley product? There's one thing
about it I don't like. When you type "tail +10c" you get all characters
starting with the tenth.
Now, that's un-Unixican. Characters start at 0, and perhaps blocks and
lines should too. As it is, if I want a shell command or expression
in the argument, I usually have to add 1 to it to make it work.
I'd like to see a program that does what tail does, except that if
you say "tail +n" it skips the first n units. You could call it
something else--maybe "trail." And how about a "head" with the same
syntax as tail/trail? ("head xx file; tail xx file" = "cat file")
--
Col. G. L. Sicherman
UU: ...{rocksvax|decvax}!sunybcs!colonel
CS: colonel@buffalo-cs
BI: colonel@sunybcs, csdsiche@ubvms
Volume-Number: Volume 9, Number 20
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!husc6!ut-sally!std-unix
From: std-u...@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: tail in 1003.2 Commands
Message-ID: <6966@ut-sally.UUCP>
Date: Tue, 27-Jan-87 22:18:09 EST
Article-I.D.: ut-sally.6966
Posted: Tue Jan 27 22:18:09 1987
Date-Received: Wed, 28-Jan-87 23:37:06 EST
References: <6710@ut-sally.UUCP> <6783@ut-sally.UUCP> <6882@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 19
Approved: j...@sally.utexas.edu
From: decwrl!nsc!nsc!nsta!instable.ether!amos (Amos Shapir)
Date: Mon, 19 Jan 87 16:54:53 -0200
Organization: National Semiconductor (Israel) Ltd.
>From: colo...@sunybcs.UUCP (Col. G. L. Sicherman)
>I'd like to see a program that does what tail does, except that if
>you say "tail +n" it skips the first n units. You could call it
>something else--maybe "trail." And how about a "head" with the same
>syntax as tail/trail? ("head xx file; tail xx file" = "cat file")
Try 'dd bs=n skip=1' - actually, what you need is a 'line' modifier to
dd, in addition to chars, blocks and k.
--
Amos Shapir
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel
(011-972) 52-522261 amos%nsta@nsc 34.48'E 32.10'N
Volume-Number: Volume 9, Number 25
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!husc6!ut-sally!std-unix
From: std-u...@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-ID: <6978@ut-sally.UUCP>
Date: Wed, 28-Jan-87 12:29:30 EST
Article-I.D.: ut-sally.6978
Posted: Wed Jan 28 12:29:30 1987
Date-Received: Thu, 29-Jan-87 06:28:14 EST
References: <6710@ut-sally.UUCP> <6783@ut-sally.UUCP> <6818@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 48
Approved: j...@sally.utexas.edu
From: ihnp4!alberta!ncc!lyndon (Lyndon Nerenberg)
Date: 15 Jan 87 21:26:58 GMT
Organization: Nexus Computing Corp., Edmonton, AB
> From: g...@brl.arpa (Douglas A. Gwyn)
> Date: Thu, 8 Jan 87 11:32:58 EST
> Organization: Ballistic Research Lab (BRL), APG, MD.
>
> >From: hoptoad!...@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.
Given that UUCP is not considered part of the standard, each vendor would
be free to provide whatever software they desired. Is not the end result
of this going to be a vast number of systems, running a "standard" OS,
that will not be able to communicate with each other due to "non-standard"
communications software?
I don't disagree that the days of UUCP are numbered, however I am very
much in favor of maintaining communications compatibility between
existing and new systems. (Life is tough enough when two sites running
'g' protocol can't even talk to each other).
It would be nice if the standard actually *documented* the 'g' protocol,
and required vendors to support it (with the rising popularity of X.25,
perhaps 'f' protocol should be added as well). This would maintain the
backwards compatability necessary to keep existing networks functional,
something of primary importance to a large part of the Unix community.
It will take quite some time for the Unix community at large to adopt
a replacement for UUCP. If we simply drop UUCP from the standard, we
are inviting absolute anarchy!
Everyone who participates in this newsgroup influences (to some
degree) the thoughts of the committee. We do this via USENET, which
is brought to you through the (dubious) miracle of UUCP. Doesn't it
seem a bit silly to "unstandardize" the software that helped us
develop the standard... :-)
With Flame Catcher in hand,
--
Lyndon Nerenberg - Nexus Computing Corp. - lyn...@ncc.UUCP
UUCP: {ihnp4,ubc-vision,vax135,watmath}!alberta!ncc!lyndon
Volume-Number: Volume 9, Number 31
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!husc6!ut-sally!std-unix
From: std-u...@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-ID: <6979@ut-sally.UUCP>
Date: Wed, 28-Jan-87 12:48:55 EST
Article-I.D.: ut-sally.6979
Posted: Wed Jan 28 12:48:55 1987
Date-Received: Thu, 29-Jan-87 06:28:39 EST
References: <6710@ut-sally.UUCP>, <6783@ut-sally.UUCP> <6863@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 15
Approved: j...@sally.utexas.edu
Summary: cpio has more than just one use
From: akgua!mtgzz!...@seismo.css.gov (b.d.szablak)
Date: 16 Jan 87 13:44:21 GMT
Organization: AT&T, Middletown NJ
> > 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).
I rarely use cpio to create tapes, but I often use cpio... Principally
for transmitting via uucp et. al. multiple files (a cpio file is more
manageable), and for moving and copying files in directory hierarchies.
Volume-Number: Volume 9, Number 32
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!husc6!ut-sally!std-unix
From: std-u...@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-ID: <7000@ut-sally.UUCP>
Date: Thu, 29-Jan-87 12:09:16 EST
Article-I.D.: ut-sally.7000
Posted: Thu Jan 29 12:09:16 1987
Date-Received: Fri, 30-Jan-87 06:51:19 EST
References: <6710@ut-sally.UUCP> <6783@ut-sally.UUCP> <6863@ut-sally.UUCP> <6979@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 16
Approved: j...@sally.utexas.edu
From: guy%gorod...@Sun.COM (Guy Harris)
Date: 29 Jan 87 07:05:00 GMT
Organization: Sun Microsystems, Mountain View
>I rarely use cpio to create tapes, but I often use cpio... Principally
>for transmitting via uucp et. al. multiple files (a cpio file is more
>manageable), and for moving and copying files in directory hierarchies.
Yes, but "tar" can be used to do the same things, and is available on
more systems. Since the interchange format (which is *not* a tape
format, BTW, but an "Archive/Interchange File Format", so you can use
it to transmit hierarchies with UUCP, "rcp", etc.) is an extended
form of "tar"s, "tar" might be the more useful program to
standardize.
Volume-Number: Volume 9, Number 34
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbosgd!ulysses!gatech!ut-sally!std-unix
From: std-u...@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: tail in 1003.2 Commands
Message-ID: <7001@ut-sally.UUCP>
Date: Thu, 29-Jan-87 18:09:35 EST
Article-I.D.: ut-sally.7001
Posted: Thu Jan 29 18:09:35 1987
Date-Received: Sat, 31-Jan-87 01:50:20 EST
References: <6710@ut-sally.UUCP> <6783@ut-sally.UUCP> <6882@ut-sally.UUCP> <6966@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 37
Approved: j...@sally.utexas.edu
From: guy%gorod...@Sun.COM (Guy Harris)
Date: 29 Jan 87 07:20:35 GMT
Reply-To: g...@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
>>From: colo...@sunybcs.UUCP (Col. G. L. Sicherman)
>>I'd like to see a program that does what tail does, except that if
>>you say "tail +n" it skips the first n units.
sed -n '<n>,$p'
will do the job quite nicely.
>>And how about a "head" with the same syntax as tail/trail?
>>("head xx file; tail xx file" = "cat file")
>
>Try 'dd bs=n skip=1' - actually, what you need is a 'line' modifier to
>dd, in addition to chars, blocks and k.
Well, 4BSD has such a "head" command, and writing one for systems
lacking it would probably take less work than adding a "line"
modifier to "dd" (which would be totally inappropriate for "dd", just
as "-v" is inappropriate for "cat"). On the other hand,
sed -n '1,<n>p'
will do the job quite nicely here, too. (I suspect it may still read
the rest of the file, but sticking in optimizations to avoid this are
left as an exercise to the reader.)
Let's not use 1003.2 as a chance to add every feature we want to some
UNIX command, or to tweak their behavior to fit something that seemed
convenient one day last month, or to add our favorite command. The
commands standardized in 1003.2 should be *tools* - such as, to pick
a random example, "sed".
Volume-Number: Volume 9, Number 35
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbosgd!ulysses!gatech!ut-sally!std-unix
From: std-u...@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-ID: <7002@ut-sally.UUCP>
Date: Thu, 29-Jan-87 18:18:05 EST
Article-I.D.: ut-sally.7002
Posted: Thu Jan 29 18:18:05 1987
Date-Received: Sat, 31-Jan-87 01:51:36 EST
References: <6710@ut-sally.UUCP> <6783@ut-sally.UUCP> <6818@ut-sally.UUCP> <6978@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 40
Approved: j...@sally.utexas.edu
From: guy%gorod...@Sun.COM (Guy Harris)
Date: 29 Jan 87 07:01:22 GMT
Reply-To: g...@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
>It would be nice if the standard actually *documented* the 'g' protocol,
It can't do that until it is clear that the specification of this
protocol can be published without violating the trade secret of UNIX.
It may be that this is the case, considering Lauren Weinstein has
built an independent UUCP implementation by watching the packets fly
by, but I'd want to check first.
(Obviously, if the standard *didn't* document the 'g' protocol,
putting UUCP in the standard would be of little use - it'd be like
requiring that a system support creating AF_INET sockets with the
"socket" call, but neglecting to require that these sockets use TCP,
UDP, etc.)
Don't forget, though, that there's more to UUCP than just the "g"
protocol; you'd also have to document its file-transfer protocol that
sits on top of "g", etc. Fortunately, this is fairly simple-minded,
but it would have to be included. You'd also have to document the
format of "X." files, since UUCP without "uux" has limited use.
>and required vendors to support it (with the rising popularity of X.25,
>perhaps 'f' protocol should be added as well).
And perhaps 't' or 'e', for use over 8-bit-transparent
flow-controlled and reliable data paths.
>It will take quite some time for the Unix community at large to adopt
>a replacement for UUCP. If we simply drop UUCP from the standard, we
>are inviting absolute anarchy!
Do you have a practical alternative? It's not enough to predict dire
consequences if something isn't standardized; you have to demonstrate
that it is practical to standardize it.
Volume-Number: Volume 9, Number 36
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: r...@seismo.css.gov (Rick Adams)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-ID: <7037@ut-sally.UUCP>
Date: Sun, 1-Feb-87 16:27:02 EST
Article-I.D.: ut-sally.7037
Posted: Sun Feb 1 16:27:02 1987
Date-Received: Sun, 1-Feb-87 22:45:23 EST
References: <6710@ut-sally.UUCP> <6783@ut-sally.UUCP> <6818@ut-sally.UUCP> <7002@ut-sally.UUCP>
Sender: std-u...@ut-sally.UUCP
Organization: Center for Seismic Studies, Arlington, VA
Lines: 25
Approved: j...@sally.utexas.edu
Summary: documenting uucp protocols
Lack of documention of the uucp protocols should not be enough to
keep it out of the standard.
I could document all of the necessary uucp protocols, file formats, etc
WITHOUT violating ATT trade secrets or looking at the source.
(The debugging output, a line monitor and cating the files in the spool
directory provide all of the information necessary)
Documenting the 't' and 'f' protocols is trivial because it's not att
code.
However, documenting the 'g' protocol would be a royal bitch without looking
at the source code.
It seems that it would be in ATT's interest to have uucp part of the standard,
so it seems reasonable that they would be willing to give permission to
document the 'g' protocol by looking at the source. I can't conceive of
any competitive loss to them by documenting the 'g' protocol.
If IEEE can get ATT's permission and would want to add the uucp programs
to the standard, I'll document the protocols.
---rick
Volume-Number: Volume 9, Number 43