🚀 go-pugleaf

From: hoptoad!gnu@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

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

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

From: gwyn@brl.arpa (Douglas A. Gwyn)
Date:     Thu, 8 Jan 87 11:42:08 EST
Organization: Ballistic Research Lab (BRL), APG, MD.

>From: pyramid!utzoo!henry (Henry Spencer)

I generally agree with Henry's comments.

At the last 1003 meeting, I distributed a command set
proposal along these lines (it covers just what seems to
be current referred to as the Execution command set,
since I think it is a major mistake for 1003.2 to try to
standardize the language, network, or interactive
interface environments).  Unfortunately the 1003 meeting
was concurrent with X3J11 so I didn't get to hang around
for much of the 1003 discussion.  I urge that 1003.2 take
my proposal as guidelines for trimming down the Execution
command set from the SVID descriptions.  Legislating
unnecessary implementation constraints and some of the
more dubiously designed UNIX software might make AT&T
marketing happy, but it should make UNIX grokkers unhappy.


Volume-Number: Volume 9, Number 13

From: gwyn@brl.arpa (Douglas A. Gwyn)
Date:     Thu, 8 Jan 87 11:32:58 EST
Organization: Ballistic Research Lab (BRL), APG, MD.

>From: hoptoad!gnu@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

From: seismo!hadron!jsdy@sally.utexas.edu (Joseph S. D. Yao)
Date: 10 Jan 87 02:20:18 GMT
Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA

In article <6783@ut-sally.UUCP> hoptoad!gnu@lll-crg.arpa (John Gilmore) writes:
>I suggest that "cpio" be excluded.  Maybe they'll stop distributing
>System V on byte-order-dependent cpio tapes if it becomes non-standard.
>Volume-Number: Volume 9, Number 7

As I understand it, cpio as it currently stands is ASCII (not binary),
in a perfectly understandable format (reasonable byte-by-byte order)
on magnetic tape or byte-oriented file.  The problem is with magtape
interfaces that assume, e.g., little-endian order on a big-endian
machine; and transform
	byte0
	byte1
	byte2
	byte3
to
	byte1 | byte0 | byte3 | byte2
instead of
	byte0 | byte1 | byte2 | byte3
(the classic NUXI problem).
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
			jsdy@hadron.COM (not yet domainised)

Volume-Number: Volume 9, Number 16

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

> From: gwyn@brl.arpa (Douglas A. Gwyn)
> >From: hoptoad!gnu@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@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

From: colonel@sunybcs.UUCP (Col. G. L. Sicherman)
Date: 12 Jan 87 15:18:10 GMT
Organization: Jack of Clubs Precision Instruments

> From: hoptoad!gnu@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

From: seismo!cmcl2!phri!roy@sally.utexas.edu (Roy Smith)
Date: Sun, 18 Jan 87 09:48:11 est
Organization: Public Health Research Inst. (NY, NY)

[ The square brackets below were apparently inserted by Roy Smith;
they were not added by the moderator.  -mod ]

> From: colonel@sunybcs.UUCP (Col. G. L. Sicherman)
> Now, that [having tail count from 1 instead of 0 is] 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.

	While we're it, make "cmp" call the first character in a file 0.
At least on my 4.2BSD system, cmp says the first character in a file is 1.
I would imagine most people only use cmp to test for equality of files, but
I had reason to use the output of "cmp -l" the other day in a shell script
and got burned my this.  Most likely, somebody needs to carefully go
through every command in the book and ferret out count from 0/1 problems.

	Along those lines, what does it mean when some processor says
"error in line 0, file foo"?  On the one hand, it makes computer sense to
call the "first" line/character/block/whatever of a file 0.  On the other
hand, it is very convienent to reserve "error in line 0" to mean "something
went wrong before I even got a chance to start reading the file."
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

Volume-Number: Volume 9, Number 24

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: colonel@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

From: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Date:     Tue, 20 Jan 87 4:59:34 EST
Organization: Ballistic Research Lab (BRL), APG, MD.

In article <6881@ut-sally.UUCP> std-unix@ut-sally.UUCP:
>(2)  Applications should be able to use a standard interface to send
>mail.
>(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".

I am in full agreement that a SUBSET of "mail" and "lp" (or "lpr")
interfaces should be standardized, just not the whole package (for
instance, definitely NOT the interactive mail-reading interface).
My command-set proposal to 1003.2 contained several such cases of
limited subsets of what was in the SVID.  I view 1003.2 primarily
as a collections of tools for use by application programs, not as
things a naive user would confront directly.

>We have failed if we create yet another
>variant that's not a subset of most of the existing ones.

There is little value in restricting the 1003 standards to lowest-
common denominator subsets of existing UNIX implementations, since
many interesting and useful applications simply cannot be written
to work well within such a limited subset.  Consequently, the 1003.1
trial-use standard already differs in several (relatively minor, we
hope) ways from existing UNIX systems.  POSIX conformance will require
a certain amount of change to existing systems.  We've been working
fairly closely with AT&T SVID people on this issue, in an attempt to
ensure that a system can be simultaneously SVID and POSIX compliant
without requiring separate "universes" (libraries, etc.).

As one of the original separate-universe implementors, I wish to
state that any such implementation should be viewed as an interim
measure while we attempt to converge on a single universal standard.
(I believe this is what Sun is attempting to do.)  It will sure be
nice to be able to quit worrying about annoying trivial system
variations and get to work on better applications.

Volume-Number: Volume 9, Number 27

From: seismo!mcnc.org!ecsvax!bet (Bennett Todd)
Date: Mon, 19 Jan 87 14:26:45 est
Organization: Duke User Services

>From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
>
>> From: gwyn@brl.arpa (Douglas A. Gwyn)
>> >From: hoptoad!gnu@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.
>...
>(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?

Because UUCP is distinctive among UNIX applications in having "secrets"
buried inside it. To be a UUCP a utility should, at a minimum, be able
to communicate successfully with at least some large proportion of all
existing implementations; unfortunately, the protocol isn't documented
for potential implementors. The only reasonable way to get the protocol
is to read the source code; this makes your resulting implementation a
derivative work and therefore AT&T proprietary. It is *not* appropriate
to produce a standard mandating something which is strictly AT&T
proprietary.

Actually, I have heard of one (1) instance of a UUCP being written and
not beholden to AT&T. However, with substantially less effort than is
required to work from a line trace up and reverse engineer the protocol,
you can produce a complete replacement that works far better in several
important respects (e.g. built-in quoting to enable transparent
transmission through 7-bit communication channels, support for various
flow control mechanisms including the terrible XON/XOFF, ability to work
efficiently in the face of long round-trip packet delays and/or half
duplex, logon dialog specification far more flexible than "expect-send
strings", and so forth). If you want the ability to intercommunicate
with arbitrary other UNIX systems, write a host end portably.

Let's not go out of our way to put roadblocks in the way of competition;
AT&T already isn't the only source for substantially UNIX-like operating
systems; they aren't the only ones who could make available a POSIX
compatible operating system, if gratuitous obstructions like UUCP (with
its undocumented protocol) are avoided.

-Bennett
-- 
Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695
UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet
BITNET: DBTODD@TUCC.BITNET -or- DBTODD@TUCCVM.BITNET -or- bet@ECSVAX.BITNET
terrorist, cryptography, DES, drugs, cipher, secret, decode, NSA, CIA, NRO.

Volume-Number: Volume 9, Number 28

From: hadron!jsdy@seismo.css.gov (Joseph S. D. Yao)
Date: 26 Jan 87 14:36:44 GMT
Organization: Hadron, Inc., Fairfax, VA

In article <6881@ut-sally.UUCP> hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) writes:
>There are several points here, and I didn't make things very clear.
>> From: gwyn@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.

Yes, is miscommunication.  (tm)UNIX is a trademark of Bell Labs,
and now a Registered Trademark of AT&T.  Only those folk have
the right to standardise it.  And they have:  "System V (ex-III):
consider it The Standard."  They issued the SVID (System V Interface
Desciption).  And then re-wrote it: twice, so far.

POSIX, P1003.2, is a Standard for An Operating System Interface.
Note that it's called POSIX, and not that registered trademark.
Yes, it looks a lot like our favourite OS that's better than any
other OS out there (yet).  No coincidence.  But it doesn't have
to look exactly like any existing version.

However, the quote above referred specifically to the Shell!  Not
to the OS, but to the user interface.

BTW, I rather agree that such things as UUCP, mail, et al.
should be mentioned in the standard at least by reference or
in an appendix as minimal interfaces.  But room should be
allowed to make these replacable by updated facilities, and
perhaps even to be made an optional package.
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
			jsdy@hadron.COM (not yet domainised)

Volume-Number: Volume 9, Number 29

From: ihnp4!alberta!ncc!lyndon (Lyndon Nerenberg)
Date: 15 Jan 87 21:26:58 GMT
Organization: Nexus Computing Corp.,  Edmonton, AB

> From: gwyn@brl.arpa (Douglas A. Gwyn)
> Date:     Thu, 8 Jan 87 11:32:58 EST
> Organization: Ballistic Research Lab (BRL), APG, MD.
> 
> >From: hoptoad!gnu@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. - lyndon@ncc.UUCP
UUCP: {ihnp4,ubc-vision,vax135,watmath}!alberta!ncc!lyndon

Volume-Number: Volume 9, Number 31

From: guy%gorodish@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

From: guy%gorodish@Sun.COM (Guy Harris)
Date: 29 Jan 87 07:20:35 GMT
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View

>>From: colonel@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

From: guy%gorodish@Sun.COM (Guy Harris)
Date: 29 Jan 87 07:01:22 GMT
Reply-To: guy@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

From: guy%gorodish@Sun.COM (Guy Harris)
Date: 29 Jan 87 07:12:50 GMT
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View

>	While we're it, make "cmp" call the first character in a file 0.
>At least on my 4.2BSD system, cmp says the first character in a file is 1.

"cmp" hasn't changed a lot, so all the other AT&T-derived "cmp"s do
this.

>I would imagine most people only use cmp to test for equality of files, but
>I had reason to use the output of "cmp -l" the other day in a shell script
>and got burned my this.  Most likely, somebody needs to carefully go
>through every command in the book and ferret out count from 0/1 problems.

If people actually use the output of "cmp" in shell scripts, you
can't just "make 'cmp' call the first character in a file 0", since
this may break shell scripts.  You do, however, have to document
whether it calls that byte 0 or 1, and you also have to document
precisely the format of its output, so you *can* use it in shell
scripts.

>	Along those lines, what does it mean when some processor says
>"error in line 0, file foo"?  On the one hand, it makes computer sense to
>call the "first" line/character/block/whatever of a file 0.

For characters and blocks, maybe.  For lines, it may make computer
sense, but not a lot of sense otherwise.  Text editors currently call
the first line line 1, and even people exposed to C for prolonged
periods of time do so as well (probably because their text editor
does...).

>On the other hand, it is very convienent to reserve "error in line 0" to
>mean "something went wrong before I even got a chance to start reading the
>file."

Convenient for the programmer writing the code printing the error
message, maybe, but that doesn't count.  What counts in this case is
convenience to the *user*, and an error message that leaves the line
number out entirely - and even the file name, if the error doesn't
pertain to the file - is far more convenient there.

When some program says "error in line 0, file foo", it generally
means the programmer who wrote that code was too lazy to get the
error message right.

Volume-Number: Volume 9, Number 38

>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... :-)

Perhaps you use UUCP, but I use DOD Internet protocols and
don't wish to have UUCP forced on my environment.

Network standards are a whole nother ball game and do NOT
belong in the POSIX standard.

Certainly a real-world computer system will benefit from
standards other than POSIX, for example, graphics standards.
That doesn't mean that POSIX needs to include such standards.

Volume-Number: Volume 9, Number 53

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

As far as I am aware, the details of the UUCP protocol are not
considered a trade secret by AT&T, although the UNIX software
that implements that protocol certainly is.  I think it's more
a matter of nobody taking the time to write it down.

I saw a detailed description of the UUCP protocol go by on the
comp.mail.uucp newsgroup the other day.  It appeared to be
deduced from "black box" treatment, except that the "g" protocol
document was written by its author: Greg Chesson.  (I don't know
the release status of that document, only that it seems to be
generally available, since it was posted to Usenet by someone who
is not associated with AT&T.)

In any case, the protocol evidently IS documented, and this documentation
is generally available.  If there is interest in standardizing UUCP,
I doubt AT&T will object, and their representatives on the POSIX
committee will have every opportunity to do so if I'm wrong.

Personally, I feel that UUCP ought to be standardized, but not as
part of the base system, but as an optional extension.  I think that
market demands will be sufficient to require most vendors to support
it, but they will be unable to without an appropriate standard unless
they use AT&T derived code.  We may feel that UUCP will be dead in a
few years, but I seem to recall that Mike Lesk described UUCP as a
quick kludge to get us by until we all had real networks (and he said this
in 1978.)

	Mark

Volume-Number: Volume 9, Number 44

Hey, has anyone ever asked the nice folks at AT&T whether they'd be willing 
to publish specs for UUCP's protocol?  It seems likely that they just might 
do it, at least for the 'g' and 'f' protocols.  If they are really serious 
about wanting us to consider Sys/V "the Standard", it seems that it would be
in their interests to make it in fact the standard.  Maybe they would even
be willing to let the IEEE (1003.7?) publish the specs. 

It seems like it oughta be worth at least an inquiry or three.

-- 
	John M Chambers			Phone: 617/364-2000x7304
Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193

Volume-Number: Volume 9, Number 50

In article <7037@ut-sally.UUCP> rick@seismo.css.gov (Rick Adams) writes:
>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.

Maybe I'm missing something here. What is wrong with the following scenario:

1) Rick Adams (or someone else) documents all the protocols, even if he has
   to look at the source.
2) He publishes said protocol definitions, without publishing a single line of
   source.
3) Rick does NOT write any new code to implement the protocols.
4) I (or someone else) take Rick's publication and using just that document,
   write brand new code to implement the protocol.

In other words, what is wrong with person A reading the code and publishing
just the protocol, person B using JUST the protocol to write code, and person A
not writing any code? After all, it seems everyone agrees that the protocols
themselves are not copyrighted by AT&T, just the code that implements them.
-- 
Arnold Robbins
CSNET:	arnold@emory	BITNET:	arnold@emoryu1
ARPA:	arnold%emory.csnet@csnet-relay.arpa
UUCP:	{ akgua, decvax, gatech, sb1, sb6, sunatl }!emory!arnold

Volume-Number: Volume 9, Number 45

It was suggested that someone could read the UNIX source code and then
publish a document on the uucp protocols without violation of copyright.
That would let the rest of the world freely implement uucp-compatible
systems.

It may be true that copyright wouldn't be violated (although in this
scenario you might be walking a thin line), but this would certainly
violate the UNIX source code license agreement.  The license is a contract
between AT&T and the person receiving the source code.  Among other
things, it calls for the protection of the source code as a trade
secret.  As a trade secret, the methods used as well as the actual
code are both protected.  You can reverse engineer by looking at the
behavior of a binary system or by reading the published documents, but
you can't reverse engineer by reading the source code without violating
the license agreement.

/Michael Tilson, HCR Corporation
/{utzoo,...}!hcr!mike

Volume-Number: Volume 9, Number 52