std-unix@ut-sally.UUCP (Moderator, John Quarterman) (12/23/86)
From: seismo!amdahl!hlj@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 72std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/08/87)
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
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/08/87)
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 10std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/08/87)
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 11std-unix@ut-sally.UUCP (01/10/87)
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 13std-unix@ut-sally.UUCP (01/10/87)
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
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/15/87)
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
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/15/87)
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
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/18/87)
From: <rbj@icst-cmr.arpa> (Root Boy) Jim Cottrell Date: Tue, 13 Jan 87 03:58:08 EST > From: <gwyn@brl> (Doug 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. Yes, and some of us with ARPA access refuse to believe UUCP exists. > >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 live with cpio as a replacement for tar, altho I would always force the -c option. > >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! It works both ways. You also can't find a `diff -r' in TPC UNIX. Who needs `dircmp'? As for shells, does TPC even use Bourne's anymore? Isn't Korn's upward compatible? So do we mandate Korn's? All in all, I find this effort biased too much towards TPC and away from BSD. If we are to do that, I would rather start with V7 as a base rather than SV. Most UNIXen are derived from V7. Let's keep the standard that way too. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> Volume-Number: Volume 9, Number 21
std-unix@ut-sally.UUCP (01/28/87)
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
std-unix@ut-sally.UUCP (01/28/87)
From: akgua!mtgzz!bds@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
std-unix@ut-sally.UUCP (01/29/87)
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
std-unix@ut-sally.UUCP (01/30/87)
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
std-unix@ut-sally.UUCP (02/01/87)
>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
rick@seismo.css.gov (Rick Adams) (02/02/87)
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
std-unix@ut-sally.UUCP (02/02/87)
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
std-unix@ut-sally.UUCP (02/04/87)
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
std-unix@ut-sally.UUCP (02/07/87)
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 52LOGNAME@ut-sally.UUCP (02/11/87)
In article <7111@ut-sally.UUCP>, gwyn@brl.arpa (Doug Gwyn) writes: > 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. This is exactly why we need "optional standards". True, not everyone wants UUCP or TCP, but it would help greatly if the standards said something like: "You don't have to implement the UUCP or TCP packages, but if you choose to do so, they should behave as follows...." [ There already are standards for the TCP/IP suite. -mod ] For another example, we wouldn't expect everyone to support the C-shell, but if they have something called "/bin/csh", then it really should be a C-shell, and not some other sort of program with an unrelated function. [ That is probably within the scope of 1003.2. It is not within the scope of 1003.1, i.e., POSIX, nor are network standards within the scope of either. There is a /usr/group Working Group on that subject, as reported in mod.std.unix Volume 9, Number 49 Message-Id: <7091@ut-sally.UUCP>: /usr/group Working Group on Network Interface: Gil McGrath AT&T Information Systems (201)522-6182 -mod ] Despite UUCP's problems, it is in fact a useful off-the-shelf file-transfer package. I'd like to see it part of a standard package, though if "rcp" were available, I'd certainly use it rather than "uucp". Now, as for kermit.... [ Rcp is not part of the standard TCP/IP suite. It may never be, as many people hope it will vanish entirely in favor of distributed file system standards. See also /usr/group Working Group on Distributed File System: Dave Buck D.L. Buck & Associates, Inc. 6920 Santa Teresa Bldg, #108 San Jose, CA 95119 (408)972-2825 -mod ] -- 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 54