Message-ID: <anews.Aucbvax.5570>
Newsgroups: fa.unix-wizards
Path: utzoo!decvax!ucbvax!unix-wizards
X-Path: utzoo!decvax!ucbvax!unix-wizards
From: ucbvax!unix-wizards
Date: Sun Dec 27 00:40:17 1981
Subject: criticisms of Unix
>From mclure@SRI-UNIX Sun Dec 27 00:28:24 1981
By far the criticism I hear most often from new Unix users is the atrocious
naming of commands. They urge `cat' be renamed to `ty', `rm' to `del',
`grep' to `search', etc.
When they argue this way, there's little to be said. They are absolutely
right. Is there *any* hope of making Unix commands more reasonable?
Message-ID: <anews.Asri-unix.406>
Newsgroups: net.unix-wizards
Path: utzoo!decvax!ucbvax!menlo70!sri-unix!cosell@BBN-UNIX
X-Path: utzoo!decvax!ucbvax!menlo70!sri-unix!cosell@BBN-UNIX
From: cosell@BBN-UNIX
Date: Sun Jan 3 23:27:09 1982
Subject: On
From: Bernie Cosell <cosell@BBN-UNIX>
I have been trying hard (successfully so far) to stay out of this, but there
has now been enough misguided commentary on the matter of command names that I
can't hold out any longer.....
The folk who think that making `rm' simply become `del' has ANY bearing on the
real fundamental problem have totally missed the point of the criticism.
Further, such stroke-of-the-magic-wand isn't-UNIX-wonderful expedients
only exacerbate the whole situation, rather than helping it.
The problem is not any particular name (although there are many really
losing names, `cat' among them - `grep' ain't so good either). The
troubles span such problems as the unstructured laissez-faire chaos of
naming/argument/switch/default conventions (or, more properly,
non-conventions) coupled with a total disdain (for the most part) by
the various applications programmers (since, to be sure, they get little
or no help or guidance from the system) as to the confusion the chaos makes
for users and the damage that ensues when users make otherwise-innocent
(and simple) errors (and this extends to the kernel; for example, doing
`glob' at shell level instead of in the kernel and the lack of version
numbers condemn users to an irregular, disaster-prone environment).
The criticisms of particular tiny pieces of UNIX that (repeatedly) get
made are NOT intended as `fix these if you can' challenges, but rather
as illustrations -- instances of the general, overall problems. If you
don't understand what the real, fundamental, underlying problems are,
then your fixes and suggestions (quickies or otherwise) are almost
certainly going to be off the mark. If you believe that UNIX's problems
are bad public relations and a few easily-patched-around minor glitches,
then you're missing the point.
/Bernie
Message-ID: <anews.Asri-unix.413>
Newsgroups: net.unix-wizards
Path: utzoo!decvax!ucbvax!menlo70!sri-unix!clyde@utexas-11
X-Path: utzoo!decvax!ucbvax!menlo70!sri-unix!clyde@utexas-11
From: clyde@utexas-11
Date: Mon Jan 4 19:30:13 1982
Subject: Reply to: On
There are a number of problems with your complaints.
True, renaming cat to type misses the point of the criticism (but
it does make DEC-acclimated folks happy).
The intrinsic problem with UNIX is that it was released
upon the academic world while still a "programmers' system", and
thusly lots of people got used to "cat", "grep" and such. I don't
find "grep" (Global Regular Expression Pattern) to be that bad a
name, partially because there are few programs like it on any
other system (DEC doesn't provide one, a fact that I've sorely
missed on our DEC-20s here).
But there is another point of the UNIX philosophy that
you have missed -- simplicity. The kernel provides low-level
support for user programs, and thus doesn't eat the machine alive
with system overhead (I shudder to think of the gnashing for the
TOPS-20 COMND JSYS, as neat as it is). Functions such as glob and
the shell BELONG AT USER LEVEL.
What should happen is for BTL to restructure UNIX utility
names and say "OK guys, this is the standard." The likelihood of
this being the case is slim, for UNIX is already caught in the
trap of any successful system -- one can't suddenly change
everybody's world when there are a LOT of everybodys. Also the
lassie-faire UNIX support by WE contributes to this.
So where are we left in the meantime? If you have
sufficient demand for a particular form of command naming, I
would suggest ln /bin/cat /bin/type (at least to placate your
users). Additionally let people know about your unhappiness with
the command mnenomics (the greatest hope I see is with the UCB
people, since their UNIX is a de facto standard for VAXen).
-------
Message-ID: <anews.Asri-unix.416>
Newsgroups: net.unix-wizards
Path: utzoo!decvax!ucbvax!menlo70!sri-unix!cosell@BBN-UNIX
X-Path: utzoo!decvax!ucbvax!menlo70!sri-unix!cosell@BBN-UNIX
From: cosell@BBN-UNIX
Date: Mon Jan 4 19:35:24 1982
Subject: Re: Reply to: On
From: Bernie Cosell <cosell@BBN-UNIX>
I agree that almost all of UNIX's problems can be traced back to the almost
neurotic compulsion to keep things `simple'. There are two basic ways in which
simplicity nails the user: first, it requires EVERY applications programmer to
`roll his own' (command parsing, argument and default conventions, etc, etc),
and second it assumes that its user are capable of `rolling their own'.
The first property insures that applications programs will be maximally
different and difficult to use. The second is the most unfortunate part (and
the very underpinnings of the misguided `suggestions' that have been appearing
here recently): the folk who CAN `roll their own' for the most part don't
see any problem! They are (apparently) perfectly content to be condemned to
having an open manual perpetually by their side and still `lose' in bizarre
ways every now and then, not to mention remembering the dozens and dozens of
special cases and caveats that aren't even in the manual. Thus, when
confronted with (well placed!) complaints about the irrationality and
irregularity of the WHOLE user environment, they are either not sympathetic or
miss the point entirely.
/Bernie
Message-ID: <anews.Asri-unix.433>
Newsgroups: net.unix-wizards
Path: utzoo!decvax!ucbvax!menlo70!sri-unix!gwyn@UTEXAS-11
X-Path: utzoo!decvax!ucbvax!menlo70!sri-unix!gwyn@UTEXAS-11
From: gwyn@UTEXAS-11
Date: Tue Jan 5 22:38:33 1982
Subject: Reply to: On
Yes, UNIX can be made more regular.
No, this is not symptomatic of a system design flaw.
People who want TENEX (or whatever) should get themselves one.
Some of us NEED a small i/o multiplexer kernel that permits us to
build applications on top without undue interference. This doesn't
need to be UNIX, but UNIX satisfies the requirement rather well.
As I have suggested before, if you have to supply computer services
to naive users on your UNIX, you can easily build a nice menu-driven
(or whatever you prefer) login shell for them. The standard shell
is best for people who LIKE plumbing and such. Some of us do.
It WOULD be nice if there were "recommended" argument schemes. G.C.
will be supplying one candidate on the next USENIX conference tape.
I don't think one could design a flexible argument interface
such as UNIX's without some fool programmer coming up with a complex
scheme for his particular application. Yet I have no desire to be
prohibited from using the argument scheme according to application
needs just to keep SOMEONE from using a peculiar design.
-------
Message-ID: <anews.Asri-unix.435>
Newsgroups: net.unix-wizards
Path: utzoo!decvax!duke!chico!zeppo!harpo!houxi!ihnss!ucbvax!menlo70!
sri-unix!cosell@BBN-UNIX
X-Path: utzoo!decvax!duke!chico!zeppo!harpo!houxi!ihnss!ucbvax!menlo70!
sri-unix!cosell@BBN-UNIX
From: cosell@BBN-UNIX
Date: Tue Jan 5 22:42:12 1982
Subject: Re: Reply to: On
I knew I was going to get in deep on this one...
The idea that `you can just write a menu hack for the naive' is EXACTLY
the kind of narrow thinking that makes UNIX difficult. The fact is that
EVERY damn command uses its own made-up (frequently stupid) argument
conventions, and so even if you are very clever about the menu, building
it to do any kind of a reasonble job of prompting users and helping them
get the calling sequences right is a HORROR. Not to mention that this
all has to be done on a pipepiece-by-pipepiece basis, since being able
to set up a pipe properly is pretty important. it would probably be
easier to just rewrite the front ends of every program to be cleaner
than to try to keep track of each fool program's conventions.
In terms of specific things, like a TENEX-style `COMAND' Jsys, or making
`glob' more useful, it may well be the case that it is not necessarily a
`kernel function', but certainly one can hardly argue with perhaps
having such functions standardly available in libc.a and providing LARGE
amounts of pressure on everyone to use the thing (just as there was
pressure to gravitiate everything to `stdio' with V7 and to use
`structures' properly instead of ad hoc arrays that happened to be the
right size for something). The lament of those of us that rue the
current situation is that the cat is long since, probably irretrievably,
out of the bag: YEARS ago there should have been some effort given to
making various user-level things uniform across the system. Now, I fear,
there are just too many strange programs with strange conventions to
be able to make much of a dent on it all with any sensible amount of effort.
I am hard pressed to believe that you are arguing in favor of being
undisciplined and irresponsbile, all in the sake of `not getting in your
way'.
[after all, we are not talking about Civil Liberties here: we
are talking about the obligations of systems level folk to
well-engineer things they foist on their users. Part of the
baggage of becoming a `wizard' is dealing with the
responsibilities. We can certainly discuss `what makes for
standards that are both structured enough and flexible
enough' to make sense, but my responsibility to the folk in my
user community pretty much make me bow out of discussions on
the virtues of doing poor engineering; they expect me to use
my time on their behalf more wisely]
So I can only infer that you presume that the simple provision of `rules'
for various things (and standard libraries, routines and the like) will
somehow interfere with your doing something useful. That certainly wasn't
true on TENEX (I don't know about TOPS 20).
On TENEX, we mostly had no help from the monitor, but aeons ago, when the
`EXEC' was first being writting somebody (Ray Tomlinson, I think) wrote a
wonderful little piece of code that took a table description of what your
args are allowed to be, what types they are, where to store the values,
etc. and handled all of the ESC completion and ? giving you hints about
what was expected next. This is not too hard a routine to write, and if it
is reasonably well organized should not too badly interfere with your
ability to do anything sensible you want. The trouble is getting it
integrated into all of the existing programs (I believe, as it was on TENEX
pretty much, that once it was thought out and made available, even the
craziest of yahoos would use it in preference to crudely hacking out
something on their own). Similarly, I don't think that USER's much care
where `*' are expanded, except so far as the fact that doing it in the shell is
both the quickest-and-dirtiest place to do it, and very nearly the least
useful. Ditto with damn regular expressions: there should have been a library
routine to handle that a long time ago so that at least all of the programs
that talk `RE' will talk about the same functionality. The list of places
where a little bit of clear thought, a library routine (or a syscall)
and a little `word from on high' to encourage the use of the new stuff
would have made DRAMATIC improvements in UNIX's overall appearance and
functionality.
[ For example, consider something that the TENEX folk
got WRONG: they never made rules requiring (and
setting standards for) documentation. Too late into
the game, they tried to `clean up their act', and have
mostly ended up with an incredible hodgepodge of
places where useful bits of documentation were stuck;
all in different, ad hoc formats ranging from a page
of assembly code (roughly the equivalent of using
something like /usr/include/math.h as your `manual
page' for the math library) right through full
phototypesetter-ready encoded files, with a liberal
collection of UNIX-style manual pages in between.
Lord only knows I hate being `slowed down' by the
obligation to write reasonable manual pages for
anything I do, but certainly we have to admit that
life would be virtually unbearable even for us hardy
non-naive users if every damn application and video
editor and this and that started showing up WITHOUT a
manual page to go with it. You'd go nuts! ]
Just a brief scan through the UNIX manual will quickly reveal how terrible
things can get if everything is done without some rules in force. I HATE
it that I have to always make room on my desk to keep a (bulky!) UNIX
manual available for constant reference. How can anyone prefer or defend
having to remember whether or not a swtich for a particular program ought
to be prefixed with `-' or not, or if there are two switches if they go `-a
-b' or `-ab'; How about output file: some just use the last file name on
the line, others like a `-o' in front of it. The list of stupidities
perpetrated for lack of a sensible standard go on and on, and to no purpose
that I can see.
In terms of being a `small I/O level multiplexor', I think you are in the
wrong game: UNIX is hardly `small' as Operating systems go and all but the
most simpleminded of I/O is mostly difficult to do: if it ain't a vanilla
`char at a time' device, it mostly won't integrate well, and you'll
probably end up with some abortion like the old V6 mag tape devices (don't
know if they fixed them up for V7 or not); doing a real-time system is
virtually impossible. (we're not planning on even TRYING to use UNIX for
our real-time systems!) If you want a klunky, minimal system that mostly
lets you do any damnawful thing you want to any kind of strange device, you'd
be better off using something like CMOS.
/Bernie
Message-ID: <anews.Awatmath.1379>
Newsgroups: net.unix-wizards
Path: utzoo!decvax!watmath!bstempleton
X-Path: utzoo!decvax!watmath!bstempleton
From: watmath!bstempleton
Date: Tue Jan 5 22:02:12 1982
Subject: Re: Reply to: On
On the name of grep, as I thought, it was a condensation of
g/re/p (aka qed or ed) where p is for print instead of pattern.
'Regular expression pattern' is a bit redundant.
Message-ID: <anews.Awhuxlb.120>
Newsgroups: net.unix-wizards
Path: utzoo!decvax!duke!chico!harpo!whuxlb!ech
X-Path: utzoo!decvax!duke!chico!harpo!whuxlb!ech
From: whuxlb!ech
Date: Wed Jan 6 03:16:55 1982
Subject: Reply to UNIX Objections
At last, I see someone object to UNIX in a way which might actually be
MEASURABLE: that UNIX fails to supply a sufficiently strong development
environment, so the gurus have to repeatedly "roll their own," so (aha:
the bottom line) everybody else has to put up with widely varying options,
formats, etc.
OK, now let's calm down a bit, and try to be scientists (as opposed to
evangelists) for a moment. A couple of observations: first, I find no
particular problem with having a manual by my side at my terminal. The
things I use every day I rarely have to consult the manual for; the things
I use rarely I DO consult the manual for. I submit that this is an entirely
reasonable way to do business and that, moreover, when dealing with any
complex artifact (like a programming environment), this is a reasonable way
to do business. My lawyer keeps his law library close at hand, my mechanic
keeps Chilton close at hand, and so on for anyone who deals with complex
artifacts in a professional manner.
Second, at the risk of sounding obsessive and/or defensive, the only example
of an environment that I have encountered which truly held my hand and led
me through the steps was TENEX (or TOPS-20, very nearly the same thing from
the user's point of view). Even there, the more complex programs (compilers,
editors, etc.) require fairly heavy ARCHIVAL documentation, including
reference manuals, tutorials, etc. There is simply no way yet devised for
ANY computer system to simply read my mind and perform what I want performed;
I must necessarily LEARN TO USE THE TOOL, and using the tool well necessarily
includes reference on an on-going basis to archival information.
Third, as Milton Friedman is fond of saying (oh, gosh, I just revealed that
I am a compulsive/obsessive/reactionary/defensive capitalist lackey, too!),
you cannot compare something real with something ideal. I will stipulate
that the UNIX environment is on a par with the seventh circle of hell;
what would you LIKE TO SEE short of the telepathic natural language computer?
Sorry, sarcasm a little thick in places...now let me be constructive:
I work with Human Factors people (mostly Experimental Psychologists) every day;
they are scientists who manage to formulate and conduct REAL experiments with
REAL subjects and analyze the results with REAL statistics to reach USABLE
conclusions. Note that this kind of real SCIENCE has very little to do with
broadsides like the now-infamous Norman article in Datamation. Such
broadsides are fine publicity and may bring in lots of grant money, but they
are hardly constructive.
Why not? Again: how would you change UNIX? Or would you chuck it entirely?
But that is the same question: hell, I am one of those damn professionals
who can (and has) used environments that make the ninth circle look good;
I don't CARE what the interface looks like, cuz I will find SOME way to cut
out a niche I can be comfortable in. I know what is comfortable for ME,
and that happens to be what was comfortable for Ken Thompson, so...
SO TELL ME WHAT YOU WANT. But that is NOT the same as telling me what you
DON'T want. And I am no more telepathic than the machine. Give me
MEASURES. Give me TOOLS. I really AM obsessive about wanting the stuff I
build to be of maximal benefit to the maximal number of people, so I try
to keep interfaces clean and documentation clear. Show me how to do a better
job and I will do it.
End of flame. Obviously, UNIX serves a certain group of people well.
Obviously, it could serve other people better. The really silly thing is
that the flexibility is there to do the very experiment that need to be done
to find out how to do better. Let's use it.
=Ned Horvath=
Message-ID: <anews.Acbosgd.1332>
Newsgroups: net.unix-wizards
Path: utzoo!decvax!duke!chico!zeppo!harpo!cbosg!cbosgd!mark
X-Path: utzoo!decvax!duke!chico!zeppo!harpo!cbosg!cbosgd!mark
From: cbosgd!mark
Date: Wed Jan 6 10:21:12 1982
Subject: Re: Reply to: On
In case anyone cares, "grep" does not stand for "Global Regular Expression
Pattern", it stands for the ed command
g/r.e./p
Admittedly pretty obscure, but we've defined a new word, folks!
As to the UNIX command names, yes, they are unfortunate, but they are
both firmly established and short (=easy to type). Making a link might
help briefly, but then your users learn to use "ty" instead of "cat",
and while they think they know UNIX, they go to the next system and it
doesn't work. I don't like the Bourne Shell syntax either, but I can
sure see the advantages of having one undisputable standard (having both
sh and csh around causes LOTS of confusion.)
However, the ln solution misses one of the points I've heard people make.
They say "10 systems let me type any unambiguous abbreviation for my
command, thus 'ty', 'typ', or 'type' all work". Creating links for all
the abbrs is kind of overkill. Given the directory/path structure of
modern UNIX, I don't see any reasonable way to do this abbreviation stuff
in the shell. But rumor has it that Stanford has a csh hacked up to do
TENEX EXEC style command completion/abbreviation. It would be real interesting
to see how they did it.
Message-ID: <anews.Acbosgd.1353>
Newsgroups: net.unix-wizards
Path: utzoo!decvax!ucbvax!mhtsa!harpo!cbosg!cbosgd!mark
X-Path: utzoo!decvax!ucbvax!mhtsa!harpo!cbosg!cbosgd!mark
From: cbosgd!mark
Date: Wed Jan 6 11:38:51 1982
Subject: Re: Reply to: On
Note that UNIX 3.0 has a standard subroutine called "getopt(3)" which
parses argc/argv vectors in a convenient, high level, CONSISTENT manner.
The only thing stopping the outside world from using it is that it
wasn't in any released version of UNIX before. Even if the code itself
can't be passed freely to non-3.0 licensees, certainly the manual pge
can be used to rewrite it outside the labs (it can't be very much code)
and a compatible standard can be promoted by Berkeley.