NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/unix/wizards/4872

Text File | 1992-11-24 | 142.7 KB | 3,645 lines

Path: sparky!uunet!elroy.jpl.nasa.gov!ames!sun-barr!cs.utexas.edu!rutgers!cmcl2!adm!news
From: [e-mail] (SMTP MAILER)
Newsgroups: comp.unix.wizards
Subject: Mail not delivered yet, still trying
Message-ID: <[e-mail]>
Date: 23 Nov 92 23:01:12 GMT
Sender: [e-mail]
Lines: 3635


 ----Mail status follows----
Have been unable to send your mail to <[e-mail]>,
will keep trying for a total of eight days.
At that time your mail will be returned.

 ----Transcript of message follows----
Date: 22 Nov 92 03:24:00 EST
From: [e-mail]
Subject: UNIX-WIZARDS Digest  V17#002
To: "DGRAY" <[e-mail]>

Return-Path: <[e-mail]>
Received: from SEM.BRL.MIL by milo.starlab.csc.com with SMTP ;
          Sun, 22 Nov 92 03:20:23 EST
Received: from SEM.BRL.MIL by SEM.BRL.MIL id ab25769; 21 Nov 92 7:47 EST
Received: from sem.brl.mil by SEM.BRL.MIL id aa25655; 21 Nov 92 7:29 EST
Date:       Sat, 21 Nov 92 07:29:30 EST
From:       The Moderator (Mike Muuss) <[e-mail]>
To:         [e-mail]
Reply-To:   [e-mail]
Subject:    UNIX-WIZARDS Digest  V17#002
Message-ID:  <[e-mail]>

UNIX-WIZARDS Digest          Sat, 21 Nov 1992              V17#002

Today's Topics:
                     Re: Keyboard hit in C programs
                 Re: Detecting if running under chroot
                       Re: The Problem with UNIX
      Re: The Problem with UNIX [Includes ANCIENT Usenet traffic]
                       Re: The Problem with UNIX
       Re: >>TAR file on tape distroyed, are files recoverable?<<
                        SCCS ID Keywords problem
                               Re: RPCGEN
               Re: Any TeX (compilation) Gurus out there?
            Problem with Window to Window commands.... HELP!
                        Closing ends of pipe().
                             TTYDEFS Help!
                 Re: HELP! problem with tar PC <-> SUN
        Verbose errors on demand - was Re: The Problem with UNIX
               RESULT: comp.arch.bus.vmebus passes 227:19
                    Re: Does Linux use segmentation?
                           system call write

-----------------------------------------------------------------

From: walter misar <[e-mail]>
Subject: Re: Keyboard hit in C programs
Keywords: Keyboard hit, C programs, UNIX
Date: 10 Nov 92 14:54:17 GMT
Sender: The News System <[e-mail]>
Nntp-Posting-Host: rbhp69.rbg.informatik.th-darmstadt.de
To:       [e-mail]

In article <[e-mail]>, bernt@valois (Bernt Skottun) writes:
>
> I am in the process of adapting a C program from the PC for
> the UNIX environment (for SUN 3 running SUNOS 4.1.1).
> In this program it is essential that
> the user be able to stop certain parts of the program
> (e.g. an inner loop) by hitting the keyboard (any key
> is fine) while as long as the keyboard is not touched the execution
> of the program will continue un-interupted (thus a procedure
> which requires, or expects, the user to type in a key stroke at certain
> intervals will not do). In the DOS environment
> I have been able to do this with the "kbhit()" function.
> My question is: what is the equivalent function in the UNIX
> environment? or how does one go about creating such a function?
> Any suggestions will be very welcome. Thanks a lot.
> Bernt Skottun, [e-mail]
>

Ok, since ^C is an 'any key' you only have to catch the SIGINT you
get if ^C is hit.

#include <signal.h>
signal(SIGINT,function)

In function() ( prototyped as void function(void) ) the first call should
be signal(SIGINT,function) because the behavior of SIGINT is reset to default
by the signal-handler.

Walter

-----------------------------

From: Klaus Mueller <[e-mail]>
Subject: Re: Keyboard hit in C programs
Keywords: Keyboard hit, C programs, UNIX
Date: 13 Nov 92 16:18:18 GMT
Sender: The News System <[e-mail]>
Nntp-Posting-Host: rbhp59.rbg.informatik.th-darmstadt.de
To:       [e-mail]


In article <[e-mail]>, you write:
>
> I am in the process of adapting a C program from the PC for
> the UNIX environment (for SUN 3 running SUNOS 4.1.1).
> In this program it is essential that
> the user be able to stop certain parts of the program
> (e.g. an inner loop) by hitting the keyboard (any key
> is fine) while as long as the keyboard is not touched the execution
> of the program will continue un-interupted (thus a procedure
> which requires, or expects, the user to type in a key stroke at certain
> intervals will not do). In the DOS environment
> I have been able to do this with the "kbhit()" function.
> My question is: what is the equivalent function in the UNIX
> environment? or how does one go about creating such a function?
> Any suggestions will be very welcome. Thanks a lot.
> Bernt Skottun, [e-mail]
>

Here is a solution to this problem that not even requires to poll the the
the keyboard. It uses SIGIO to get notified, but the program continues with
the loop after the signalhandler  has returned. So you have to think about
leaving the loop after execution continues :).

I don't know how portable this is, my system is HP-UX. The relevant man-pages
are: termio(7) and ioctl(5).


#include <sys/ioctl.h>
#include <unistd.h>
#include <signal.h>
#include <stdio.h>
#include <termio.h>

struct termio term_old;

void resetfiles(void) {        /* resets all terminalstat we have changed */
    int arg;

    arg = 0;
    if (ioctl(STDIN_FILENO, FIOSSAIOSTAT, &arg)==-1) {
        perror("unset async");
        exit(1);
    }
    if (ioctl(STDIN_FILENO, TCSETA, &term_old) == -1) {
        perror("set termios");
        exit(1);
    }
}

void handler(int dummy) {    /* handels the SIGIO */
    printf("got it\n");
    resetfiles();    /* clear what we have done */
    exit(0);
}

int main (void) {
    int arg;
    struct termio term;

    arg = getpid();    /* tell the keyboard _we_ want the signal */
    if (ioctl(STDIN_FILENO, FIOSSAIOOWN, &arg)==-1) {
    perror("set owner");
    resetfiles();
    exit(1);
    }

            /* tell the system we want a _signal_ */

    arg = 1;
    if (ioctl(STDIN_FILENO, FIOSSAIOSTAT, &arg)==-1) {
    perror("set async");
    resetfiles();
    exit(1);
    }

        /* keep the old stats */

    if (ioctl(STDIN_FILENO, TCGETA, &term_old) == -1) {
    perror("get termio1");
    resetfiles();
    exit(1);
    }

        /* and get some stats we can change */

    if (ioctl(STDIN_FILENO, TCGETA, &term) == -1) {
    perror("get termio2");
    resetfiles();
    exit(1);
    }
    term.c_lflag &= ~ICANON;          /* get the charcters immediately */
    term.c_cc[VMIN] = (char) 0;        /* no char buffered */
    term.c_cc[VTIME] = (char) 0;    /* and no timeout */

        /* use our new settings */

    if (ioctl(STDIN_FILENO, TCSETA, &term) == -1) {
        perror("set termios");
        resetfiles();
        exit(1);
    }

    signal(SIGIO, handler); /* where to go with the signal */

    sleep(20);        /* now let's do something (sleep) */

    resetfiles();    /* reset all we changed */
}

--
Klaus M"uller  ([e-mail])
IRC: netmage       MUD: loren

-----------------------------

From: Paul Hite <[e-mail]>
Subject: Re: Detecting if running under chroot
Date: 11 Nov 92 16:11:41 GMT
To:       [e-mail]

In article <mark.721121538@coombs>, [e-mail] (Mark) writes:
>
> I was reading some of the security texts on research.att.com and it mentioned
> that it was possible to detect if one was running under a chroot call.
>
> If the file system is duplicated etc how would you check? Make a massive file
> on the (apparent) root disk (/tmp for instance) and do a 'df' to make sure
> it's the root disk?

Well I've played around some public access bbs systems that thew me into a
chroot env.  From a practical standpoint, I quickly noticed how little I could
do.  It just had the "feel" of a chroot environment.  But I guess that you're
looking for a more formal method.  I would examine the inode of the root.  I
think something like "ls -id /" should do it.  But I still say that most
chroot'd environments that I have seen don't really need much effort to
detect.

Paul Hite   PRC Realty Systems  McLean,Va   [e-mail]    [phone]
    "We are trying to bring up an Air Traffic Control display on an X window
      terminal and there seems to be some problems." -- from comp.windows.x

-----------------------------

From: Leslie Mikesell <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 11 Nov 92 21:26:12 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (peter da silva) writes:
>>     Sending binary file should be uuencoded first.
>
>Nope. It should say "mail: Standard input contains NULL characters." And
>abort.

I disagree on this one.  It should just work unless you are of the opinion
that computers should not handle arbitrary binary data.  SysVr4 gets
this one right by checking the content before trying to display it but
not before delivering it to the right place.

Les Mikesell
  [e-mail]

-----------------------------

From: Christopher Davis <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 11 Nov 92 23:50:14 GMT
Sender: NNTP News Poster <[e-mail]>
Followup-To: comp.unix.shell
Nntp-Posting-Host: loiosh.eff.org
To:       [e-mail]

[cleaning up followups]
Mike> == Mike Hollander <[e-mail]>

 Mike> Things that bother me about the command line (I'm using Motorola
 Mike> UNIX System V/68 Release 3.71 running a Korn shell using vi-type
 Mike> command line editing on a VT420), in no particular order:

 Mike> 1) It is possible to backspace over the prompt.

Get BSD tty drivers or tcsh.

 Mike> 2) Running over past the end of the line onto the next line does not
 Mike>    allow you to backspace back to the previous line, and if you
 Mike>    backspace at the last column of a line it is possible to miss
 Mike>    a character and therefore not backspace over what you think
 Mike>    you are backspacing over.

This might be a termcap issue.  Try tcsh.

 Mike> 3) It doesn't seem possible to map the arrow keys on the keyboard
 Mike>    to enable you to press up arrow to get the previous command, or
 Mike>    to use left arrow to move backwards through the line.

tcsh.

 Mike> 4) It doesn't seem possible to store macros that could be run with
 Mike>    a single keypress.

tcsh.

 Mike> 5) The function keys don't do anything and cannot be made to do
 Mike>    anything on the command line.

tcsh.

 Mike> 6) The insert and remove keys cannot be made to place you in insert
 Mike>    mode or remove characters.

probably tcsh.  (I don't know, I don't do modes.)

 Mike> That's a short list off the top off my head. If anyone has methods
 Mike> to fix these complaints please feel free to respond!

Get tcsh. ;)

zsh and bash probably fix most or all of these complaints also.
--
Christopher K. Davis      | ``Usenet seems to run much like the Kif (or,
<[e-mail]>   EFF #14   |   for the TV generation, Klingon) high command.
System Administrator, EFF |   Whoever takes action and can be heard wins.''
[phone]  [CKD1]   |   --Peter da Silva <[e-mail]>

-----------------------------

From: Marc Unangst <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 02:06:09 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Mike Hollander) writes:
>1) It is possible to backspace over the prompt.

This is either the fault of your tty driver or your shell.  If you get
Bash, you will not be able to backspace over the prompt.  Or, you can
get SVR4 and use the BSD extensions in the tty driver, which includes
the "don't backspace over the prompt" extension.

>2) Running over past the end of the line onto the next line does not
>   allow you to backspace back to the previous line, and if you
>   backspace at the last column of a line it is possible to miss
>   a character and therefore not backspace over what you think
>   you are backspacing over.

Get a different shell.  Bash can implement this by scrolling the
command line horizontally, instead of wrapping it to the next line.  I
believe Bash also supports reverse-backspacing, but you need to make
sure your terminfo definition is correctly set up to handle wrapping
at column 80.

>3) It doesn't seem possible to map the arrow keys on the keyboard
>   to enable you to press up arrow to get the previous command, or
>   to use left arrow to move backwards through the line.

Get Bash.  It fixes this problem with ksh.

>4) It doesn't seem possible to store macros that could be run with
>   a single keypress.

Dunno if Bash can handle this.  It probably can, but I haven't looked
into it because I never needed it.  You can always make an alias or
shell function to run frequently-used commands in one or two
characters.

>5) The function keys don't do anything and cannot be made to do
>   anything on the command line.

See the generic "I can't rebind my keyboard" answer.

>6) The insert and remove keys cannot be made to place you in insert
>   mode or remove characters.

This is fixed by using a modeless editor, like Emacs.  I suppose you
could always rebind ESC to INS and "x" to RMV, but that still doesn't
fix the root of the problem.  If you use the Emacs editing mode, you
won't need an "insert mode" (since you're always in insert mode), and
you can just rebind delete-char to whatever your "remove" key sends.

FYI, Bash is the GNU Bourne Again Shell.  If it sounds like the be-all
and end-all of shells, well, it is.  (Or at least I think so.  Please,
I don't really want to get into a my-shell-is-better-than-your-shell
flame war...)  It is available from a GNU archive site near you, or
you can get it from prep.ai.mit.edu:/pub/gnu/bash-1.12.tar.Z.

--
Marc Unangst, N8VRH         | "There are two ways to solve this problem:
[e-mail]   | the hard way, and the easy way.  Let's start
                            | with the hard way."
                            |   - W. Scheider, from a Physics lecture

-----------------------------

From: Marc Unangst <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 02:10:03 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (peter da silva) writes:
>Just (a) fixing all applications so they call perror on failure, and (b)
>cutting down on the overloading of error messages, would do wonders.

Have you looked at SVR4.2 yet?  From what I've seen (which,
admittedly, has not been much), it looks like they've retrofitted onto
all the commands that horrible "UX:program: ERROR: ..." message format
that the LP subsystem uses under earlier versions of System V.  I
really, really wish they would have decided on something different to
use as the standard, but...

--
Marc Unangst, N8VRH         | "There are two ways to solve this problem:
[e-mail]   | the hard way, and the easy way.  Let's start
                            | with the hard way."
                            |   - W. Scheider, from a Physics lecture

-----------------------------

From: Andy Harp <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 16:08:06 GMT
X-Disclaimer: Any opinions expressed are my own.
To:       [e-mail]

In article <[e-mail]> [e-mail] (Marc Unangst) writes:
>In article <[e-mail]> [e-mail] (Mike Hollander) writes:

               Lots of stuff deleted

>>6) The insert and remove keys cannot be made to place you in insert
>>   mode or remove characters.
>
>This is fixed by using a modeless editor, like Emacs.  I suppose you
>could always rebind ESC to INS and "x" to RMV, but that still doesn't
>fix the root of the problem.  If you use the Emacs editing mode, you
>won't need an "insert mode" (since you're always in insert mode), and
>you can just rebind delete-char to whatever your "remove" key sends.
>

Presumably he is talking about vi, and you can map these keys to anything
you want (look up the map command in vi)

>FYI, Bash is the GNU Bourne Again Shell.  If it sounds like the be-all
>and end-all of shells, well, it is.  (Or at least I think so.  Please,
>I don't really want to get into a my-shell-is-better-than-your-shell
>flame war...)  It is available from a GNU archive site near you, or
>you can get it from prep.ai.mit.edu:/pub/gnu/bash-1.12.tar.Z.

Completely agree with you

>
>--
>Marc Unangst, N8VRH         | "There are two ways to solve this problem:
>[e-mail]   | the hard way, and the easy way.  Let's start
>                            | with the hard way."
>                            |   - W. Scheider, from a Physics lecture


--
 ----------------------------------------------------------------
[e-mail]       Andrew Harp, DRA Malvern, Gt. Britain
[e-mail]         tel  : [phone]
[e-mail]     DoD #0737

-----------------------------

From: Eric Eide <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 17:03:39 GMT
To:       [e-mail]

Scott Beckstead ([e-mail]) writes:

Scott> Typicaly UNIX imposes far more structure on the user than is desired.  I
Scott> agree an experienced user should be able to recognize and avoid the
Scott> problems [previously mentioned].  What's wrong with the shell catching
Scott> such obvious errors and either reporting them or taking other
Scott> appropriate action (ie correcting them)?  I realize that this will get
Scott> me screamed at by all you guru types that advocate that all shell users
Scott> be rocket scientists or why bother using a computer anyway.  However I
Scott> see no reason NOT to research the subject.  If UNIX could be made more
Scott> user friendly by modifying the shell it might gain more acceptance in
Scott> the general microcomputer market place, GUIs not withstanding.

I know of somebody who is doing research in this direction: me.  As part of my
Masters degree I am modifying the C shell to be more tolerant of errors, both
errors in syntax (e.g., typos) and semantics (e.g., inappropriate command line
arguments).  My new shell keeps track of the user's command history in order to
make accurate corrections.

I have no hopes to solve all of the shell user interface problems, but I do
hope to solve most of the common errors.  Just by fixing obvious typos my shell
can fix 90% of the command line errors that I (and most people) make on a daily
basis.

I agree with Scott: There is no good reason that command shells shouldn't make
more of an effort to understand the user.  Shells obviously can't divine the
user's intentions in all cases, but that's not a good argument for failing to
understand the user's intentions in *all* cases.

Other research has been done along similar lines.  The UC help system is a
natural-language UNIX advisor.  I vaguely remember that the Z shell does some
simple typo correction.  And way back in the predawn, Interlisp had a builtin
DWIM facility.

--
 -------------------------------------------------------------------------------
Eric Eide          |          University of Utah Department of Computer Science
[e-mail]  | Buddhist to hot dog vendor: "Make me one with everything."

-----------------------------

From: Jurgen Botz <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 18:47:42 GMT
Sender: USENET News System <[e-mail]>
To:       [e-mail]

In article <[e-mail]> [e-mail] (Mike Stefanik) writes:
>In an article, [e-mail] (Boyd Roberts) writes:
>>The real problem, as Rob has so eloquently put it:
>>
>>    ``Not only is UNIX dead, it's starting to smell really bad.''
>
>I find it amazing that people, apparently in pursuit of some small amount of
>enjoyment, spend their time proclaiming the death of UNIX. This sort of thing
>is really beginning to take on the flavor of the apocalyptic doomsayers (you
>know the type ... [...]

I agree.  Heh... Not only are those who keep pronouncing the death of
Unix dead wrong, but their credibility is starting to rot.
--
Jurgen Botz                  |   Internet: [e-mail]
Academic Systems Consultant  |     Bitnet: [e-mail]
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629

-----------------------------

From: Michael Lemke <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 19:37:07 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Eric Eide) writes:
>Scott Beckstead ([e-mail]) writes:
>
>
>I know of somebody who is doing research in this direction: me.  As part of my
>Masters degree I am modifying the C shell to be more tolerant of errors, both
>errors in syntax (e.g., typos) and semantics (e.g., inappropriate command line
>arguments).  My new shell keeps track of the user's command history in order to
>make accurate corrections.
>
>I have no hopes to solve all of the shell user interface problems, but I do
>hope to solve most of the common errors.  Just by fixing obvious typos my shell
>can fix 90% of the command line errors that I (and most people) make on a daily
>basis.
>

Well, fixing typos is neat but it is not the essential problem.  My
main complaint about Unix on the user interface level is that there is
no command line interpreter.  What I mean is that after the shell munged
your command line it is *completely* up to the program to interpret the
command line and there is no system function available to parse even
these `standard' options.  Some programs use one letter chinese (you
know, one character per word) and others (eg, find) use words (-print
-name).  And the real problem then starts when -l changes its meaning
from command to command, some commands need spaces between the option
and the argument, others don't, some take both, yech.  This would all be
solved if there were *one* system function that is used by all programs
instead of having every program duplicate more or less the same
functionality with different success.  And it would be great if you
could abbreviate commands (command completion of some shells it neat
but why is it neccessary in the first place?) and options (no need for
dynamic chinese anymore).

>I agree with Scott: There is no good reason that command shells shouldn't make
>more of an effort to understand the user.

Computer:  Calculate the weather forecast for Sunday, Nov 15!

Yes, I would appreciate this... :-)

>Shells obviously can't divine the
>user's intentions in all cases, but that's not a good argument for failing to
>understand the user's intentions in *all* cases.
>

Does AI work now?

--
Michael Lemke
Astronomy, UT Austin, Texas
([e-mail] or UTSPAN::UTADNX::IO::MICHAEL [SPAN])

-----------------------------

From: Karl Anderson <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 20:47:10 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Scott Beckstead) writes:
>
>  I think this is kinda what he is trying to determine.  Typicaly UNIX
>imposes far more structure on the user than is desired.  I agree an
>experienced user should be able to recognize and avoid the problems
>above.  What's wrong with the shell catching such obvious errors and
>either reporting them or taking other appropriate action (ie correcting
>them).  I realize that this will get me screamed at by all you guru

Is there any reason why there can't be another stream for more
user-friendly messages?  We have stdin and stderr, why can't there be
a standard verbose stream as well?  Experienced users could just
direct it to /dev/null , or, to save cpu time, could have a flag that
would disable it altogether.

k

>Reply to: [e-mail]     |

-----------------------------

From: Eric Eide <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 20:47:22 GMT
To:       [e-mail]

Michael Lemke ([e-mail]) writes:

Michael> Well, fixing typos is neat but it is not the essential problem.  My
Michael> main complaint about Unix on the user interface level is that there is
Michael> no command line interpreter.  What I mean is that after the shell
Michael> munged your command line it is *completely* up to the program to
Michael> interpret the command line and there is no system function available
Michael> to parse even these `standard' options.

It sounds as if you are proposing the invention of an application-independent
command line parser that does more than just syntactic processing (as provided
by getopt()).  This would definitely be interesting -- but is it really
possible?  What would it look like?  What would the universal meaning of `-l'?

If there were such a command line parser, it would certainly reduce the amount
of knowledge that my smart shell requires.  As it is now, I basically have to
describe the syntax of every program that I want to be "smart" about.  The
shell is an unusual program in the sense that most of its "command set" is
implemented by entities that have no real connection to the shell itself.  And
obviously, it's hard to be smart about things you know nothing about :-).  For
this reason I've sometimes thought that I made a poor choice in deciding to
make a "smart shell" for my thesis.  But on the other hand, the shell is the
most commonly used program with a command line interface, so perhaps a "smart
csh" is much more valuable that a "smart ftp."

Michael> Some programs use one letter chinese (you know, one character per
Michael> word) and others (eg, find) use words (-print -name).  And the real
Michael> problem then starts when -l changes its meaning from command to
Michael> command, some commands need spaces between the option and the
Michael> argument, others don't, some take both, yech.  This would all be
Michael> solved if there were *one* system function that is used by all
Michael> programs instead of having every program duplicate more or less the
Michael> same functionality with different success.

If I understand you correctly, you're basically making a call for standard
syntax.  I'm all for it.  Now as for the standard semantics (e.g., the
universal interpretation of `-l'), that's definitely up in the air.

Michael> Does AI work now?

You're begging the question of whether or not AI ever worked.  For a suitable
definition of AI, AI has always worked :-).

--
 -------------------------------------------------------------------------------
Eric Eide          |          University of Utah Department of Computer Science
[e-mail]  | Buddhist to hot dog vendor: "Make me one with everything."

-----------------------------

From: [e-mail]
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 22:14:05 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Leslie Mikesell) writes:
> In article <[e-mail]> [e-mail] (peter da silva) writes:
> >>     Sending binary file should be uuencoded first.

> >Nope. It should say "mail: Standard input contains NULL characters." And
> >abort.

> I disagree on this one.  It should just work unless you are of the opinion
> that computers should not handle arbitrary binary data.  SysVr4 gets
> this one right by checking the content before trying to display it but
> not before delivering it to the right place.

I disagree on this one.  I can't stand the SVr4 mail program's unwillingness
to display a file in which someone has accidentally put ONE backspace or
escape.  And of course there are nroff output files with
  _^hu_^hn_^hd_^he_^hr_^hl_^hi_^hn_^h_^he  in them.

This user says `Plugh!'

(Really, until we all use some form of BLOB-linked-in-text we'll have this
argument over and over.)
--
 (This man's opinions are his own.)
 From mole-end                Mark Terribile

 [e-mail], Somewhere in Matawan, NJ

-----------------------------

From: "Antony A. Courtney" <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 22:36:08 GMT
Sender: "NN required at ashe.cs.tcd.ie" <[e-mail]>
Nntp-Posting-Host: unix1.tcd.ie
To:       [e-mail]

In <[e-mail]> [e-mail] (Mike Stefanik) writes:
>In an article, [e-mail] (Boyd Roberts) writes:
>>The real problem, as Rob has so eloquently put it:
>>
>>    ``Not only is UNIX dead, it's starting to smell really bad.''
>
>I find it amazing that people, apparently in pursuit of some small amount of
>enjoyment, spend their time proclaiming the death of UNIX.
> [...]
>I have heard UNIX to be proclaimed dead and buried for years now.
> [...]
>So, Boyd, if UNIX really is dead, where is the funeral? I would so enjoy
>paying my last respects ...

UNIX once referred to a research operating system which was very cleanly
designed on a coherent set of principles, and whose structure was well within
the intellectual grasp of a single human being.

There exists a certain class of modern operating systems, all of which are
referred to by the name UNIX.  These operating systems have their origins in
the system I refer to above, but have "enhanced" the original system with lots
of new "features" which you and I find useful (terminal handling, job control,
networking, etc.).  But in the process of adding all of these new "features" to
UNIX, these new operating systems somehow lost the brevity, clarity, simplicity
and structural elegance of that other system once called UNIX.

UNIX is dead.  Long live UNIX.

[all of the above are obviously purely my own opinions...]

    -antony

>--
>Mike Stefanik  [e-mail]  ...!uunet!pacsoft!mike  [phone]
>Pacific Software Group, Riverside, CA
--
********************************************************************************
* Antony A. Courtney                              Email: [e-mail] *
* Computer Science Department                            [e-mail] *
* Trinity College, Dublin, Ireland                Phone: 01+353+1-607389       *

-----------------------------

From: "Bryan S. So" <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 23:18:45 GMT
Sender: The News <[e-mail]>
To:       [e-mail]

Concerning "cat a b > b", [e-mail] writes:

>It has been solved. There are at least two solutions:
>    1) Educate the user. After all the system did exactly what
>        the user told it to do.
>    2) in csh/tcsh, do "set noclobber"
>
>grymoire% set noclobber
>grymoire% touch a b
>grymoire% cat a b >b
>b: File exists.
>--
>Bruce Barnett <[e-mail]> uunet!crdgw1!barnett

No, the above are not solutions.

1. We should assume some stubborn users cannot be educated.  I
   claim without proof such users exist.

2. set noclobber is not a solution because a solution should
   prepend a to b.

I propose a real solution to this problem.  Change the internal
policy of UNIX, so that when any file is used as both input and
output, like

    cat a b > a
or     cat a b > b

UNIX should read and buffer all input before opening the output
with "w".


Bryan

-----------------------------

From: Rich Kulawiec <[e-mail]>
Subject: Re: The Problem with UNIX [Includes ANCIENT Usenet traffic]
Date: 13 Nov 92 00:24:02 GMT
Sender: [e-mail]
Nntp-Posting-Host: gynko.circ.upenn.edu
To:       [e-mail]

I've included a sharchive at the end of this with the full text of
Don Norman's paper and some comments that various netfolks made at that
time.  If I recall correctly, this was the first instance of a Usenet
forgery -- he claimed that the paper was sent without his knowledge --
and so a couple of the messages deal with that issue rather than
with the points raised in his paper.  I got quite a kick out of
reading these messages again 11 years later; it's kind of interesting
to look back on these with a decade's perspective.

By the way, you'll notice a paucity of headers in those old messages;
that might make identifying people difficult.  I believe that "ber"
is Brian Redman, csvax.mark is Mark Horton, jej is James Jones,
nowicki is Bill Nowicki, mo might be Mike O'Brien, and utzoo!henry
is Henry Spencer.

In article <[e-mail]> [e-mail] (Bryan S. So) writes:
>Concerning Don Norman's paper "The Trouble With UNIX", Datamation 27,
>[e-mail] (Rich Kulawiec) writes:
>
>>Norman's paper is (a) a decade out-of-date and (b) extraordinarily
>>inaccurate, as it was when published.  In my opinion, it represents
>>the uninformed rantings of someone who is simply too lazy to read the
>>manuals and therefore should not be using a computer at all.
>
>I agree it's a decade old but can you indicate why it's inaccurate?
>
>To me, some problems like "cat a b > b" are obviously undesirable
>designs and still unsolved after more than a decade.

Nearly every problem that Norman addressed himself to was a function
of the shell, not of Unix.  "cat a b > b" is solvable at the shell
level, should it ever really become necessary to do so.  (I personally
think that people who type that deserve what they get, and that there's
no need to fix it, but I digress.)

Let me quote some choice nuggets from his paper and comment on them:

DN > I would have written a program that listed the  contents  onto
DN > the  terminal,  perhaps  stopping  every 24 lines if you had
DN > signified that you were on a display terminal with only a 24
DN > line  display.   To  the  designers of Unix, however, such a
DN > solution lacks elegance.  Unix has  no  basic  listing  com-
DN > mand,  but  instead you must use a program meant to do some-
DN > thing else.

"more" was already around and in widespread use when he wrote this.
In fact, Norman mentions that he's using 4BSD in his paper.

DN >     In Unix, if you wanted to list the contents of  a  file
DN >called "HappyDays", you would use the command named "cat":
DN >                       cat HappyDays
DN >Why cat? Why not?  After all, said Humpty Dumpty  to  Alice,
DN >who  is to be the boss, words or us?

The use of an alias, or 1-line shell script, easily provides the
functionality of "cat" by any name the user desires.

DN >     The standard text editor is called Ed.

Ding.

DN > [...] and  Unix  move  (mv)  and copy (cp) operations will
DN > destroy existing files without any warning.

"mv -i".  "cp -i".  Also around when he wrote his paper.

DN>      The bad news is that Berkeley Unix  is  jury-rigged  on
DN> top  of regular Unix, so it can only patch up the faults: it
DN> can't remedy them.

This belies the contributions of the CSRG team.

DN > The listing program is called "more" (as in,
DN > "give  me  more").

Ah, so he does know about "more"; then why berate "cat"?

DN > A common theme runs through  the  com-
DN > mands: don't be nice to the casual user --  write the system
DN > for the dedicated expert.  The system is a recluse.  It uses
DN > weird  names,  and it won't speak to you, not even if spoken
DN > to.  For system programmers, Unix is a delight.  It is  well
DN > structured,  with  a consistent, powerful philosophy of con-
DN > trol and structure.  My complaint is simple:   why  was  not
DN > the  same  effort  put  into  the design at the level of the user?

Actually, here, he's dead right.  Unix was written for programmers
by programmers, and the biggest mistake we've ever made as a
community was trying to dumb it down so that the average clueless
user could use it.  Let 'em have Macintoshes.  Gimme back "dsw".

---Rsk

#    This is a shell archive.
#    Remove everything above and including the cut line.
#    Then run the rest of the file through sh.
#----cut here-----cut here-----cut here-----cut here----#
#!/bin/sh
# shar:    Shell Archiver
#    Run the following text with /bin/sh to create:
#    rumor.shrink
#    rumor.ber
#    rumor.bh
#    rumor.clyde
#    rumor.eps
#    rumor.greg
#    rumor.henry
#    rumor.henry2
#    rumor.jej
#    rumor.jerry
#    rumor.mark
#    rumor.mark2
#    rumor.mo
#    rumor.nowicki
#    rumor.swd
# This archive created: Thu Nov 12 18:58:11 1992
# By:    Rich Kulawiec (GSP Whitewater Slalom Racing Team)
cat << \SHAR_EOF > rumor.shrink
From cincy!duke!decvax!utzoo!datamat!rumor Sat Aug  1 23:37:27 PDT 1981
The Truth about UNIX: fa.unix-wizards





                   The truth about Unix:
                The user interface is horrid

                      Donald A. Norman
                  Department of Psychology
                            and
                Program in Cognitive Science
          Center for Human Information Processing
            University of California, San Diego
                 La Jolla, California 92093
                 (to appear in Datamation)

     Unix is a highly touted operating system.  Developed at
the  Bell  Telephone Laboratories and distributed by Western
Electric, it has  become  a  standard  operating  system  in
Universities,  and  it promises to become a standard for the
large micro- mini- systems for  home,  small  business,  and
educational setting.  But for all its virtues as a system --
and it is indeed an elegant system -- Unix is a disaster for
the casual user.  It fails both on the scientific principles
of human engineering and even in just plain   common  sense.
The motto of the designers of Unix towards the user seems to
be "let the user beware."

     If Unix is really to become a general system,  then  it
has got to be fixed.  I urge correction to make the elegance
of the system design be reflected  as  friendliness  towards
the user, especially the casual user.  I have learned to get
along with the vagaries  of  its  user  interface,  but  our
secretarial staff persists only because we insist.  And even
I, a heavy user of computer systems for 20  years  have  had
difficulties:  copying  the old file over the new, transfer-
ring a file into itself  until  the  system  collapsed,  and
removing  all  the  files from a directory simply because an
extra space was typed in the argument string.  In this arti-
cle  I  review  both the faults of Unix and also some of the
principles  of  Cognitive  Engineering  that  could  improve
things,  not just for Unix, but for computer systems in gen-
eral.  But first, the conclusion;  Unix fails several simple
tests.

     Consistency: The command names, language, functions and
          syntax are inconsistent.

     Functionality: The command names, formats,  and  syntax
          seem to have no relationship to their functions.

     Friendliness: Unix is a recluse, hidden from the  user,
          silent  in  operation.   "No news is good news" is
          its motto, but as a result, the  user  can't  tell
          what  state  the system is in, and essentially, is
          completely out of touch with things.

     Cognitive Engineering:  The system does not  understand


                       August 2, 1981






                           - 2 -


          about  normal  folks,  the everyday users of Unix.
          Cognitive capabilities are strained  beyond  their
          limits,  the  lack  of  mnemonic structures places
          large loads of memory, and the lack of interaction
          puts  a strain on one's ability to retain mentally
          exactly what state the system is in at any moment.
          (Get  distracted  at  the  wrong time and you lose
          your place -- and maybe your file.)

What is good about Unix?   The system design, the generality
of  programs,  the  file  structure,  the job structure, the
powerful operating system command  language  (the  "shell").
To  bad  the concern for system design was not matched by an
equal concern for the human interface.



     One of the first things you learn  when  you  start  to
decipher  Unix  is  how  to list the contents of a file onto
your terminal.  Now this sounds straightforward enough,  but
in  Unix even this simple operation has its drawbacks.  Sup-
pose I have a file called "testfile".  I want to see what is
inside  of  it.   How would you design a system to do it?  I
would have written a program that listed the  contents  onto
the  terminal,  perhaps  stopping  every 24 lines if you had
signified that you were on a display terminal with only a 24
line  display.   To  the  designers of Unix, however, such a
solution lacks elegance.  Unix has  no  basic  listing  com-
mand,  but  instead you must use a program meant to do some-
thing else.

     In Unix, if you wanted to list the contents of  a  file
called "HappyDays", you would use the command named "cat":
                       cat HappyDays
Why cat? Why not?  After all, said Humpty Dumpty  to  Alice,
who  is to be the boss, words or us?  "Cat", short for "con-
catenate" as in, take file1 and concatenate  it  with  file2
(yielding  one  file,  with the first part file1, the second
file2) and put the result on the "standard output" (which is
usually the terminal):
                         cat file1 file2
Obvious right?  And if you have only one file, why cat  will
put  it  on  the standard output -- the terminal -- and that
accomplishes the goal (except for those  of  us  with  video
terminals  who  watch  helplessly as the text goes streaming
off the display).

     The Unix designers are rather  fond  of  the  principle
that  special purpose functions can be avoided by clever use
of a small set of system primitives.   Their  philosophy  is
essentially,  don't  make  a special function when the side-
effects of other functions will do what you want.  But there
are several reasons why this philosophy is bad;



                       August 2, 1981






                           - 3 -


     1. A  psychological  principle  is  that  names  should
          reflect  function, else the names for the function
          will be difficult to recall;

     2. Side-effects can be used for virtue,  but  they  can
          also  have  unwarranted  effects.  Thus, if cat is
          used unwisely, it will destroy files (more on this
          in a moment).

     3. Special functions can do nice things for users, such
          as  stop  at  the  end  of screens, or put on page
          headings,  or  transform  non-printing  characters
          into  printing  ones, or get rid of underlines for
          terminals that can't do that.

Cat, of course, won't stop at terminal or  page  boundaries,
because  if it did that, why that would disrupt the concate-
nation feature.  But still, isn't it elegant to use cat  for
listing?   Who  needs  a  print or a list command.  You mean
"cat" isn't how you would abbreviate  concatenate?  gee,  it
seems so obvious to us.  Just like
   _f_u_n_c_t_i_o_n             _U_n_i_x _c_o_m_m_a_n_d _n_a_m_e
c compiler                      cc
change working directory        chdir  (cd in Berkeley Unix)
change password                 passwd
concatenate                     cat
copy                            cp
date                            date
echo                            echo
editor                          ed
link                            ln
move                            mv
remove                          rm
search file for pattern         grep

Notice the lack of consistency in forming the  command  name
from  the  function.   Some  names  are formed  by using the
first two consonants of the function name, unless it is  the
editor  which  is  abbreviated "ed" and concatenate which is
"cat" or "date" or "echo" which are not abbreviated at  all.
Note  how  useful those 2 letter abbreviations are.  See how
much time and effort is saved typing only 2 letters  instead
of  --  heaven  forbid  --  4  letters.  So what is a little
inconsistency among friends, especially when  you  can  save
almost 400 milliseconds per command.

     Similar statements apply  to  the  names  of  the  file
directories.  Unix is a file oriented system, with hierarch-
ical directory structures, so the directory names  are  very
important.   Thus,  this  paper  is  being written on a file
named      "unix"      and       whose       "path"       is
/csl/norman/papers/CogEngineering/unix.  The name of the top
directory is "/", and csl, norman, papers, and  CogEngineer-
ing  are  the  names  of  directories  hierarchically placed


                       August 2, 1981






                           - 4 -


beneath "/".  Note that the symbol "/" has two meanings: the
name  of  the  top  level  directory  and  the  symbol  that
separates levels of the directories.  This is very difficult
to justify to new users.  And those names: the directory for
"users" and "mount" are called, of course, "usr" and  "mnt."
And  there  are  "bin," "lib," and "tmp." (What mere mortals
might call binary, library, and temp).   Unix loves abbrevi-
ations,  even  when the original name is already very short.
To write "user" as "usr" or "temp" as "tmp" saves an  entire
letter:  a  letter  a day must keep the service person away.
But Unix is inconsistent;  it doesn't abbreviate  everything
as   2  or  3  letter commands.  It keeps "grep" at its full
four letters, when it could have been abbreviated as "gr" or
"gp".  (What  does  grep mean, you may ask.  "Global REgular
expression, Print" --  at  least  that's  the  best  we  can
invent,  the  manual  doesn't  even  try  to  say.  The name
wouldn't matter if grep were something obscure, hardly  ever
used, but in fact it is one of the more powerful, frequently
used string processing commands.  But that takes me from  my
topic.)


     Do I dare tell you about "dsw"?  This also turns out to
be  an important routine.  Suppose you accidentally create a
file whose name has  a non-printing character  in  it.   How
can you remove it?  The command that lists the files on your
directory won't show non-printing characters.   And  if  the
character  is  a space (or worse, a "*"), "rm"  (the program
that removes files) won't accept it.   "dsw"  was  evidently
written  by someone at Bell Labs who felt frustrated by this
problem and hacked up a quick solution.  Dsw  goes  to  each
file  in  your  directory  and asks you to respond  "yes" or
"no," whether to delete the file  or keep it (or  is  it  to
keep it or delete it -- which action does "yes" mean?).  How
do you remember dsw?  What on earth does the name stand for?
The  Unix people won't tell; the manual smiles its wry smile
of the professional programmer and says "The name dsw  is  a
carryover  from the ancient past. Its etymology is amusing."
(The implication, I guess, is that true professionals  never
need  to  use such a program, but they are allowing it to be
released for us  novices  out  in  the  real  world.)  Which
__________________________
Verification of my charges comes from  the  experiences
of  the  many users of Unix, and from the modifications
that other people have been forced to make to the  sys-
tem.   Thus, the system of Unix I now use is called The
Fourth Berkeley Edition for  the  Vax,  distributed  by
Joy,  Babaoglu, Fabry, and Sklower at the University of
California, Berkeley (henceforth, Berkeley Unix).  They
provide   a  listing  program  that  provides  all  the
features I claim a user would want (except  a  sensible
name  -- but Berkeley Unix even makes it easy to change
system names to anything you prefer).



                       August 2, 1981






                           - 5 -


operation takes place if you say  "yes":  why  the  file  is
deleted  of course.  So if you go through your files and see
important-file, you nod to yourself and say, yes,  I  better
keep that one, type in yes, and destroy it forever. Does dsw
warn you? Of course not.  Does dsw even document itself when
it starts, to remind you which way is which?  Of course not.
That would be talkative, and true Unix programmers are never
talkative.   (Berkeley  Unix, has finally killed dsw, saying
"This little known,  but  indispensible  facility  has  been
taken  over...".   That  is a fitting commentary on standard
Unix: a system that allows an "indispensible facility" to be
"little known.")


     The symbol "*" means "glob" (a typical Unix name:   the
name  tells  you  just what action it does, right?).  Let me
illustrate with our friend, "cat." Suppose  I  want  to  put
together   a  set of files named paper.1 paper.2 paper.3 and
paper.4 into one file.  I can do this with cat:
     cat paper.1 paper.2 paper.3 paper.4 > newfilename
Unix provides "glob" to make  the  job  even  easier.   Glob
means  to  expand the filename by examining all files in the
directory to find all that fit. Thus, I can redo my  command
as
                  cat paper* > newfilename
where paper* expands to {paper.1 paper.2  paper.3  paper.4}.
This  is  one  of  the  typical virtues of Unix; there are a
number of  quite  helpful  functions.   But  suppose  I  had
decided  to name this new file "paper.all".  After all, this
is a pretty logical name, I am combining the separate  indi-
vidual files into a new one that contains "all" the previous
ones.
                   cat paper* > paper.all
Disaster.  I will probably blow  up  the  system.   In  this
case,  paper*  expands  to  paper.1  paper.2 paper.3 paper.4
paper.all, and so I am filling up a file from itself:
 cat paper.1 paper.2 paper.3 paper.4 paper.all > paper.all
Eventually the file will burst.   Does  nice  friendly  Unix
check against this, or at least give a warning?  Oh no, that
would be against the policy of  Unix.   The  manual  doesn't
bother warning against this either, although it does warn of
another, related infelicity: "Beware of 'cat a b  >  a'  and
'cat  b a > a', which destroy the input files before reading
them."  Nice of them to tell us.


     The command to remove all files  that  start  with  the
word "paper"
                         rm paper*
becomes a disaster if a space gets inserted by accident:
                         rm paper *
for now the file "paper" is removed, as well as  every  file
in  the  entire directory (the power of glob).  Why is there
not a check against such things?  I finally had to alter  my


                       August 2, 1981






                           - 6 -


version of rm so that when I said to remove files, they were
actually only moved to a special directory  named  "deleted"
and  they  didn't  actually  get deleted until I logged off.
This gave me lots of time for second thoughts and for catch-
ing  errors.  This also illustrates the power of Unix:  what
other operating system would make it so easy for someone  to
completely  change  the  operation  of  a system command for
their own personal satisfaction?  This also illustrates  the
evils  of Unix: what other operating system would make it so
necessary to do so?  (This is no longer necessary  now  that
we use Berkeley Unix -- more on this in a moment.)


     The standard text editor is called Ed.  What a  problem
that  turned  out  to  be.   It was so lovely that I spent a
whole year using it as an experimental vehicle  to  see  how
people dealt with such awful things.  Ed's major property is
his shyness; he doesn't like to talk.  You invoke Ed by say-
ing,  reasonably  enough,   "ed".  The result is silence: no
response, no prompt, no message, just silence.   Novice  are
never sure what that silence means.  What did they do wrong,
they wonder.  Why doesn't Ed say "thank you, here I am"  (or
at least produce a prompt character)?  No, not Unix with the
philosophy that silence is golden.   No response means  that
everything  is  ok.   If  something  had gone wrong, then it
would have told you (unless the system died, of course,  but
that couldn't happen could it?).

     Then there is the famous append  mode  error.   To  add
text  into  the buffer, you have to enter "append mode."  To
do this, one simply types "a",  followed  by   RETURN.   Now
everything  that  is  typed  on  the  terminal goes into the
buffer.  (Ed, true to form, does not inform you that  it  is
now  in  append mode: when you type "a" followed by "RETURN"
the result is silence, no  message,  no  comment,  nothing.)
When  you are finished adding text, you are supposed to type
a line that "contains only a . on it."  This gets you out of
append  mode.   Want  to  bet  on how many extra periods got
inserted into text files,  or how many commands got inserted
into texts, because the users thought that they were in com-
mand mode and forgot they had not left append mode?  Does Ed
tell you when you have left append mode?  Hah.  This problem
is so obvious that even the designers  knew  about  it,  but
their  reaction  was  to  laugh:  "hah-hah, see Joe cry.  He
just made the append mode error  again."   In  the  tutorial
introduction  to  Ed, written at Bell Labs, the authors joke
about it. Even experienced programmers get screwed this way,
they  say, hah hah, isn't that funny.  Well, it may be funny
to the experienced programmer, but it is devastating to  the
beginning secretary or research assistant or student  who is
trying to use friendly Unix as a word processor,  or  as  an
experimental tool, or just to learn about computers.  Anyone
can use Unix says the programmer, all you need is a sense of
humor.


                       August 2, 1981






                           - 7 -


     How good is your sense of humor?  Suppose you have been
working  on a file for an hour and then decide to quit work,
exiting Ed  by saying "q".  The problem  is  that  Ed  would
promptly quit.  Woof, there went your last hour's work. Gone
forever.  Why, if you would have wanted to save it you would
have  said  so,  right?   Thank goodness for all those other
people across the country who immediately rewrote  the  text
editor  so  that us normal people (who make errors) had some
other choices besides Ed, editors  that  told  you  politely
when  they were working, that would tell you if they were in
append or command mode,  and  that  wouldn't  let  you  quit
without  saving  your file unless you were first warned, and
then only if you said you really meant it.


     I could go on.  As I wrote this paper I sent out a mes-
sage on our networked message system and asked my colleagues
to tell me of  their  favorite  peeves.   I  got  a  lot  of
responses,  but  there  is  no  need to go into detail about
them; they all have much the same flavor about them,  mostly
commenting  about  lack  of  consistency,  about the lack of
interactive feedback.  Thus, there is no standardization  of
means  to  exit  programs  (and  because the "shell" is just
another program as far as th system is concerned, it is very
easy to log yourself off the system by accident).  There are
very useful pattern matching features (such as the "glob"  *
function),  but the shell and the different programs use the
symbols in inconsistent ways.  The Unix  copy  command  (cp)
and the related C programming language "stringcopy" (strcpy)
have reversed order of arguments, and  Unix  move  (mv)  and
copy (cp) operations will destroy existing files without any
warning.  Many programs take special  "argument  flags"  but
the  manner of specifying the flags is inconsistent, varying
from program to program.  As I said, I could go on.


     The good news is that we don't use  standard  Unix:  we
use  Berkeley  Unix.   History lists, aliases, a much richer
and more intelligent set of  system  programs,  including  a
list  program,  an  intelligent screen editor, a intelligent
set of routines for interacting with terminals according  to
their  capabilities,  and  a  job control that allows one to
stop jobs right in the middle, startup new ones, move things
from  background  to  foreground  (and  vice versa), examine
files, and then resume jobs.  And the shell has been  ampli-
fied  to  be  a more powerful programming language, complete
with file handling capabilities, if--then--else  statements,
while,  case,  and  all the other goodies of structured pro-
gramming  (see the accompanying box on Unix).

     Aliases are worthy of special comment.  Aliases let the
user  tailor the system to their own needs, naming things in
ways they themselves can remember: self-generated names  are
indeed easier to remember than arbitrary names given to you.


                       August 2, 1981






                           - 8 -


And aliases allow abbreviations that are meaningful  to  the
individual,  without burdening everyone else with your clev-
erness or difficulties.

     To work on this  paper,  I  need  only  type  the  word
"unix,"  for  I  have  set up an alias called "unix" that is
defined to be equal to the correct command to change  direc-
tories,  combined with a call to the editor (called "vi" for
"visual" on this system) on the file:
alias unix "chdir /csl/norman/papers/CogEngineering; vi unix"
These Berkeley Unix features have proven  to  be  indispens-
able:  the  people in my laboratory would probably refuse to
go back to standard Unix.

     The bad news is that Berkeley Unix  is  jury-rigged  on
top  of regular Unix, so it can only patch up the faults: it
can't remedy them.  Grep is not only still grep,  but  there
is  an  egrep  and  an  fgrep.  But worse, the generators of
Berkeley Unix have their problems: if Bell Labs  people  are
smug  and  lean,  Berkeley  people  are cute and overweight.
Programs are wordy. Special features  proliferate.   Aliases
--   the  system  for  setting  them  up  is not easy to for
beginners (who may be the people who need them  most).   You
have  to  set  them  up  in a file called .cshrc, a name not
chosen to inspire confidence!  The "period" in the  filename
means that it is invisible -- the normal method of directory
listing programs won't show it.  The directory listing  pro-
gram, ls, comes with 19 possible argument flags, that can be
used singly or in combinations.  The number of special files
that  must be set up to use all the facilities is horrendus,
and they get more complex with each new release from  Berke-
ley.   It  is vey difficult on new users.  The program names
are cute  rather  than  systematic.   Cuteness  is  probably
better  than the lack of meaning of standard Unix, but there
are be limits.  The listing program is called "more" (as in,
"give  me  more"),  the program that tells you who is on the
system is called "finger", and a keyword help file  --  most
helpful by the way -- is called "apropos."  Apropos! who can
remember that?  Especially when you need it most. I  had  to
make  up  an alias called "help" which calls all of the help
commands Berkeley provides, but  whose  names  I  can  never
remember (apropos, whatis, whereis, which).




__________________________
The system is now so wordy and  so  large  that  it  no
longer  fits  on  the  smaller machines: our laboratory
machine, a DEC 11/45, cannot hold the latest release of
Berkeley  Unix  (even  with a full complement of memory
and a reasonable amount of disc).  I write  this  paper
on a Vax.



                       August 2, 1981






                           - 9 -


     One reader of a draft of this paper -- a  systems  pro-
grammer   --   complained  bitterly:  "Such  whining,  hand-
wringing, and general bitchiness will cause most  people  to
dismiss  it as over-emotional nonsense. ...  The Unix system
was originally designed by systems programmers for their own
use and with no intention for others using it. Other hackers
liked it so much that eventually a lot of them started using
it.  Word  spread about this wonderful system, etc, the rest
you probably know. I think  that  Ken  Thompson  and  Dennis
Ritchie  could  easily shrug their shoulders and say 'But we
never intended it for other than our personal use.'"

     All the other users of Unix who  have  read  drafts  of
this paper agreed with me.  Indeed, their major reaction was
to forward examples of problems  that  I  had  not  covered.
This  complaint was unique.  I do sympathize with the spirit
of the complaint.  He is correct, but  ...    The  "but"  is
that  the  system  is  nationally  distributed, under strict
licensing agreements, with a very high charge  to  industry,
and  nominal  charges  to  educational  institutes.  Western
Electric doesn't mind getting a profit, but  they  have  not
attempted  to  worry  about the product.  If Unix were still
what it started to be, a simple experiment on  the  develop-
ment  of operating systems, then the complaints I list could
be made in a more friendly, constructive manner.   But  Unix
is  more  than  that.   It  is  taken as the very model of a
proper operating system.  And that is  exactly  what  it  is
not.

     In the development of the system aspects of  Unix,  the
designers  have  done  a  magnificent  job.   They have been
creative, and systematic.  A common theme runs  through  the
development  of  programs, and by means of their file struc-
ture, the development of "pipes" and "redirection"  of  both
input  and  output,  plus the power of the iterative "shell"
system-level commands, one can combine system level programs
into  self-tailored systems of remarkable power with remark-
able ease.

     In the development of the  user  interface  aspects  of
Unix, the designers have been failures.  They have been dif-
ficult and derisive.  A common theme runs through  the  com-
mands: don't be nice to the casual user --  write the system
for the dedicated expert.  The system is a recluse.  It uses
weird  names,  and it won't speak to you, not even if spoken
to.  For system programmers, Unix is a delight.  It is  well
structured,  with  a consistent, powerful philosophy of con-
trol and structure.  My complaint is simple:   why  was  not
the  same  effort  put  into  the design at the level of the
user?  The answer to my complaint is  a  bit  more  complex.
There  really  are no well known principles of design at the
level of the user interface.  So, to remedy the harm that  I
may  have  caused by my heavy-handed sarcasm, let me attempt
to provide some positive suggestions based upon the research


                       August 2, 1981






                           - 10 -


that  has  been done by me and by others into the principles
of the human information processing system.


     Cognitive Engineering is a new discipline, so new  that
it  doesn't  exist:   but it ought to.  Quite a bit is known
about the human information processing system,  enough  that
we  can specify some basic principles for designers.  People
are complex entities and can adapt to almost anything.    As
a  result,  designers  are often sloppy, for they can design
for themselves without realizing the difficulties that  will
be faced by other users.  Moreover, there are different lev-
els of users:  people with a large amount  of  knowledge  of
the  device  they  are about to use are quite different from
those who lack a basic understanding.  Experts are different
than novices.  And the expert who is normally skilled at the
use of some systems but who has not used it for awhile is at
a peculiar level of knowledge, neither novice nor expert.

     The three most important concepts for system design are
these:

     1.  Be consistent.  A  fundamental  set  of  principles
          ought  to  be  evolved  and  followed consistently
          throughout all phases of the design.

     2.  Provide the user with  an  explicit  model.   Users
          develop  mental  models  of the devices with which
          they interact.  If you do not  provide  them  with
          one, they will make one up themselves, and the one
          they make up is apt to be wrong.  Do not count  on
          the  user fully understanding the mechanics of the
          device.  Secretaries  and  scientists  alike  will
          share  a  lack  of knowledge of a computer system.
          The users are not apt to understand the difference
          between  the buffer, the working memory, the work-
          ing files, and the permanent files of a text  edi-
          tor.   They are apt to believe that once they have
          typed something into the system, it is permanently
          in  their  files.   They  are  apt  to expect more
          intelligence from the  system  than  the  designer
          knows  is  there.   And  they are apt to read into
          comments (or the lack of comments) more  than  you
          have  intended.   Feedback  is  of critical impor-
          tance, both in helping to establish the  appropri-
          ate  mental model and in letting the user keep its
          current state in synchrony with the actual system.

     3.  Provide mnemonic aids.  Human memory is  a  fragile
          thing.   Actually,  for  most  purposes it is con-
          venient to think of human memory as consisting  of
          two  parts:   a  short-term memory and a long-term
          memory (modern cognitive psychology is  developing
          more  sophisticated  notions than this simple two-


                       August 2, 1981






                           - 11 -


          stage one, but this is still  a  valid  approxima-
          tion).   Short-term  memory  is,  as the name sug-
          gests, limited in duration  and  quantity:   about
          five  to  seven  items is the limit.  Thus, do not
          expect a user to remember the contents of  a  mes-
          sage  for  much  longer  than it is visible on the
          terminal.  Long-term  memory  is  robust,  but  it
          faces  two difficulties:  getting stuff in so that
          it is properly organized and getting stuff out, so
          that  it  can  be  found when needed.  Learning is
          difficult, unless there is a good  structure,  and
          it is visible to the learner.  The system designer
          must provide sensible assistance to  the  user  so
          that  the  material  can be structured.  There are
          lots of sensible memory aids that can be provided,
          but  the  most  powerful  and  sensible  of all is
          understanding.  Make a system so that  it  can  be
          understood and the memory follows with ease.  Make
          the command names ones  that  can  be  understood,
          where  the  names follow from the function that is
          desired.  If abbreviations must be used,  adopt  a
          consistent policy of forming the abbreviations. Do
          not deviate from the policy, even when it  appears
          that  it  would be easier for a particular command
          to deviate:  inconsistency is an  evil.   Remember
          the  major  problem  of  any large-scale memory is
          finding the information that is  sought,  even  if
          the  information  is there someplace.  We retrieve
          things from  memory  by  starting  off  with  some
          description  of  the information we seek, use that
          description to enter their  memory  system  in  an
          attempt  to match against the desired information.
          If the designer uses cute names  and  non-standard
          abbreviations,  our  ability  to  generate a valid
          description is impaired.  As a result, the  person
          who  is  not  expert and current in the use of the
          system is apt to flounder.



     There are many ways of formatting information on termi-
nals  to  provide  useful  memory and syntax aids for users.
With today's modern terminals, it is possible to use  menus,
multiple  screens  and  windows, highlighted areas, and with
full duplex systems,  automatic  or  semi-automatic  command
completion  systems.   The  principles for these systems are
under active study by a  number  of  groups,  but  none  are
directly  relevant to my critique of the UNIX operating sys-
tem.  UNIX is designed specifically so that it can  be  used
with a wide variety of terminals, including hard copy termi-
nals.

     The problem with Unix is more fundamental.   Unix  does
not provide the user with a systematic set of principles; it


                       August 2, 1981






                           - 12 -


does not provide a simple, consistent mental model  for  the
user, consistent not only in the shell but in the major sys-
tem programs and languages; it does  not  provide  the  user
with simple memory aids that can be used to learn the system
structure and then, when  one is not completely  current  in
the  use  of  a  particular  command,  still  to  be able to
retrieve (or better, derive)  what  is  needed.   There  are
essentially  no  user help files, despite the claim that all
the documentation is on-line via the command named man  (for
manual, of course).  But "man" requires you to know the name
of the command you want information about,  although  it  is
the name that is probably just the information you are seek-
ing.

     System designers take note.  Design the system for  the
person, not for the computer, not even for yourself.  People
are  also  information  processing  systems,  with   varying
degrees   of   knowledge,  varying  degrees  of  experience.
Remember, people's short-term memories are limited in  size,
and they learn and retrieve things best when there is a con-
sistent reason for the name, the function, and  the  syntax.
Friendly systems treat users as intelligent adults who, like
normal adults, are forgetful, distracted, thinking of  other
things,  and  not  quite as knowledgeable about the world as
they themselves would like  to  be.   Treat  the  user  with
intelligence.   There  is  no need to talk down to the user,
nor to explain everything.  But give the  user  a  share  in
understanding by presenting a consistent view of the system.


























__________________________







SHAR_EOF
cat << \SHAR_EOF > rumor.ber
From uucp Fri Aug 14 11:59:42 1981 remote from pur-ee
NAharpo.423
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!mhtsa!harpo!ber
NThu Aug 13 23:31:58 1981
NYAUF
NGee whiz.  Bitch bitch bitch.  There is better documentation than
Nmanual pages provided with your unix system.  The manual page
Nis a brief description of a command, routine or concept.  It's a starting
Npoint, and frequently enough.  If you want to know more, look at the source.
N
NI think the page for lorder is terrific.  I never use lorder for anything
Nother than ordering libraries, and to have an example right there is great.
N
NAll this crap about UNIX being unfriendly and UNIX lacking documentation
Nand so on is just that.  UNIX is an operating system.  It's clean, concise,
Nand clear (at least traditionally).  The beauty of the environment that
Ngenerally surrounds a unix is that it is easilly growable by the people
Nthat use it.  If some turkey writes a poor manual page, then unix is blamed.
NLook at all the crap you have to deal with at IH because they won't permit
Na public directory for NON-STANDARD this and that.  Well I guess they want
Nto make sure nobody polutes their system.  That stinks.  But that's the only
Nway your going to censor it.  At least you can point your finger directly
Nat the computer center staff.
N
NIf you don't like a command or documentation your free to avoid it.
NOr better yet, improve it!  Unix provides an excellent program development
Nenvironment.  If you can't figure out what a syntax error is, ask someone.
NYou'll find dozens of experts in every hallway.  Why?  Because it's relatively
Neasy to comprehend.
N
NPlease don't start restricting creativity with naming standards and style
Nstandards and how many lines are permitted in a subroutine ...
NThat's almost tolerable for a project, but unix isn't a number 7 electronic
Nsump pump.  Just because management feels that 'C' and UNIX are the do-all
Nto end-all doesn't make it so.  And the attempts to fit that misconception
Nare ruining a perfectly good environment.
N
NWhy don't you send your comments to the MINI-SYSTEM newsletter in the
Nform of a modification request?  I'ld like to see an OFFICIAL response.
N
N(deep breath)
N
NNow I feel better.   Let's face it, unix is not geared to the naive user.
NSo what?  It's great for the knowledgable user.  Why bring the level
Nof excellence down to least common denominator?  For a profit!  Yeh well
Nthat's another story.  But let's try to raise the level of the users.

SHAR_EOF
cat << \SHAR_EOF > rumor.bh
From uucp Fri Aug 14 11:39:22 1981 remote from pur-ee
NAucbvax.2619
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards
NTue Aug 11 09:14:54 1981
Nunix on large machines
N>From BH@SU-AI Tue Aug 11 09:06:37 1981
NSince KLH doesn't seem to have answered the request for details on
Nwhy UNIX isn't perfect for big machines, let me try:
N
N1.  The file system is flaky.  UCB is working on some aspects of
Nthis problem but not all.  They seem to be fixing the problems in
Nwhich a disk block is added to one list BEFORE it's removed from
Nanother, which is how the file system is compromised by a system
Ncrash.  But they aren't changing the fact that overwriting a file
N(a creat with an existing name) deletes the old file right away
Nrather than on a successful close, nor are they adding an exclusive
Naccess discipline to the kernel.  (About once a month or so my
N/etc/passwd disappears when several people try to change their
Npasswords or create new accounts at once, despite supposedly
Nfoolproof lock-file code in the user programs.)
N
N2.  Debugging facilities leave a lot to be desired.  You can't
Ntype instuctions in to adb, so it's hard to patch code.  The
Nsymbol table doesn't know about things like fields in a struct,
Nso symbolic debugging only partly exists.  You can't use adb
Nstandalone to poke at a crashed system.
N
N3.  Many smaller, easily-fixed things show that UNIX was designed
Nwith a small machine in mind.  One example: the result of compiling
N"foo.c" should be called "foo", not "a.out".  Clearly they designed
Nthe naming convention for a machine without much disk space, in which
Nit was antisocial to have executable files for more than one program
Nat a time!
N
N4.  There are terminals in the world other than the model 37 TTY.
NThe UCB termcap package makes it possible for there to be a few
Nhuge, hairy user programs which support displays.  But there needs
Nto be kernel support (or the equivalent in shell support, with
Nall other user level tty interaction funneled through the shell,
Nwhich would be awkward) for things like automatically dividing the
Ndisplay screen into pieces for different processes.  The user must
Nbe able to type escape sequences of some sort to control which piece
Nhse's typing into right now.  It should be possible to write a
NTRIVIAL user program which can still fit into this display
Ndiscipline, e.g., it shoul be able to type a control-L and have that
Nmean "clear my piece of the screen".
N
N5.  Some things aren't written as efficiently as they might be.
N
NThere's more, but this will do to begin the discussion.  Mind you,
NI think UNIX is wonderful in many ways.  Pipes are great, filters
Nare great, process trees are great, etc.  Many of the flaws in UNIX
Ncould be fixed in a more or less compatible way.  (Not the one about
Ndeleting the old file too soon, though.)  (By the way, yes I know
Nyou can program around it.  The difference between an okay system and
Na great system is that you don't have to program around the great
Nsystem, you can program THROUGH it!)  It's not that the future
Nlarge-computer standard operating system should look nothing like
NUNIX, it's that the standard large-computer UNIX needs some redesign
Nbefore it gets ossified as a standard.
N
N
N

SHAR_EOF
cat << \SHAR_EOF > rumor.clyde
From uucp Fri Aug 14 11:59:13 1981 remote from pur-ee
NAucbvax.2671
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards
NThu Aug 13 10:01:32 1981
NReply to 'The Truth about UNIX'
N>From clyde@UTEXAS-11 Thu Aug 13 09:53:17 1981
N
N    While the gentelman has some cogent points, I also believe he
Nhas permanent brain damage . He is obviously used to DEC systems which
Nlike to hold lusers hands lest they damage themselves, and I had great
Ndifficulty reading completly through his treatise (diatribe?) because
Nof his own inconsistancies and notions.
N
N    Oh well, not everyone can be enthusiatic (though I noticed he
Nwrote his document on a UNIX system, using NROFF -- I wonder how
Nhe managed to hold his nose with one hand and type with the other) .
N-------
N

SHAR_EOF
cat << \SHAR_EOF > rumor.eps
From uucp Fri Aug 14 11:56:06 1981 remote from pur-ee
NAucbvax.2642
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards
NTue Aug 11 22:35:29 1981
NRe: The Truth about UNIX
N>From Eps@UCLA-SECURITY Tue Aug 11 22:31:19 1981
NThe date given on this mesage is obviously wrong;
Nit should have read "Apr 1" instead of "Aug 1."
N
N                    --Eric
N-------
N
N

SHAR_EOF
cat << \SHAR_EOF > rumor.greg
From uucp Fri Aug 14 11:43:52 1981 remote from pur-ee
NAucbvax.2643
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards
NWed Aug 12 00:12:07 1981
NYet more truth about Unix.....
N>From greg@NPRDC Wed Aug 12 00:08:58 1981
NI almost hesitate to mention this, but Donald A. Norman, the author of
N"The Truth About Unix", gets mail as "Norman at NPRDC".  (NPRDC is
Nnotorious enough; a little more won't hurt, right?)  You could send him
Ncopies of your flames to see if he might respond.  It could be a very
Ninteresting discussion.....
N----
N

SHAR_EOF
cat << \SHAR_EOF > rumor.henry
From cincy!duke!decvax!utzoo!henry Sun Aug  9 23:43:32 1981
datamat!rumor       : net.general,NET.general
There is no such system as "datamat" connected to us, nor is there
any person named "rumor" locally.  Any communication purporting to
be from such a person at such an address is either garbled or
fraudulent.  Will somebody PLEASE tell me why we are suddenly getting
tons of mail addressed to "...!utzoo!datamat!rumor", apparently related
to an unfriendly evaluation of Unix that I have never heard of and
that most certainly did not come from here?

SHAR_EOF
cat << \SHAR_EOF > rumor.henry2
From uucp Fri Aug 14 11:56:36 1981 remote from pur-ee
NAutzoo.885
Nnet.general,NET.general,fa.unix-wizards
Npur-ee!cincy!duke!decvax!utzoo!henry
NThu Aug 13 00:56:51 1981
Ndatamat!rumor
NI've now seen a copy of the infamous utzoo!datamat!rumor article
Nthat has caused all the fuss (I thank decvax!jm for mailing it to
Nme).  It most definitely DID NOT originate at or pass through
Ndecvax!utzoo, the University of Toronto Zoology department.  The
N"PDT" in its postmark strongly suggests a west-coast origin, as
Ndoes the author's affiliation, and a friend of mine who gets various
Nthings from the Arpanet community says he has seen "utzoo" on the
Ncc-list of a document that may even be the same article (we haven't
Nyet had a chance to compare notes).  THIS IS NOT US.  We may have
Na first here:  the first real live authentic name conflict on Usenet.
N[Why me, Lord?]  Would anyone knowing the possible identity of the
Nother "utzoo" please pass this information on to me?  My friend's
Ncomments suggest it may be in the Stanford area, the origin of
Nthe article itself suggests the San Diego area.
N
N                    Henry Spencer
N                    decvax!utzoo!henry
N                    [phone] (for now)
N                    [phone] (shortly)

SHAR_EOF
cat << \SHAR_EOF > rumor.jej
From uucp Fri Aug 14 11:55:22 1981 remote from pur-ee
NAihuxl.103
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!ihnss!ihuxl!jej
NThu Aug 13 20:19:50 1981
NForced Interaction, and YAUF (Yet Another Unix Flame)
NSubject: program interface to mail-like commands, Unix documentation
N
NI've run into a problem of how to automate commands that, to quote
NRitchie, "force interaction on the user whether it is wanted or not:"
Nthe primordial example is mail.
N
NIt is not clear how one could write a program that would issue the
Ncorrect commands to mail to do a particular filtering, such as "save
Nall mail from John Doe, and delete the rest after printing it offline."
Nmail expects standard input to direct it, based on what it itself has
Noutput.
N
NAny notions of a technique for writing such programs?
N
N----------------------------------------
N
NThe item about the Unix user interface was very good--one item
Nthat the author left out, though, was Unix documentation.
N
NMost notorious, I think, are the multitude of manual pages which
Nsay about the error messages that they are "self-explanatory."
NI believe that this must mean that the author intends them to be
Nmeaningful to himself.
N
NExamples:
N
N1. run-time error messages from C programs--these are QUITE machine
N    dependent; rather embarassingly so for an OS based on C as
N    Unix is, one would think.
N2. C compiler error messages, which describe every syntax error as
N    "syntax error," which may be enough for Dennis Ritchie, but
N    not for mere mortals. Another worthless error message is
N    that which describes the error in terms of compiler internals.
N    What does that have to do with the constructs the user knows?
N
NAlso quite helpful are the error codes one gets from make(1), such as
N"Error code 100".
N
NManual pages are frequently vague and casual: I recall the times when
NI had to try VERY hard to persuade someone that egrep(1) should treat
N'$' as just another character when it is not at the end of a regular
Nexpression, and in another case, that ed(1) permitted nested escaped
Nparentheses in regular expressions. Formal specifications of options
Nand accepted commands may not be useful to some readers, but they cer-
Ntainly are more useful to those who CAN understand them than vague
NEnglish prose.
N
N"Casualness" at times degenerates into flippancy or display of the
Nauthor's self-estimated cleverness: e.g.
N
N    "This brash one-liner intends to build a new library from
N    existing .o files." (This sentence, with absolutely NO other
N    explanation, accompanies an example of lorder(1).)
N
Nor
N
N    "This is an area where experience and informed courage
N    count for much."
N
NWhat good do these do to the reader who is trying to figure out
Nwhat on EARTH a command does?
N
NOptions on commands, in a sense documentation, don't have much chance
Nto indicate their meaning, since they're typically restricted to one
Nletter. (Some day I intend to write a phony command page containing
N
N    SYNOPSIS
N        cmd -[abcdefghijklmnopqrstuvwxyz] name ...
N
N    OPTIONS
N        -a    Use the 'a' option.
Netc.)
N
N                James Jones (ihuxl!jej)

SHAR_EOF
cat << \SHAR_EOF > rumor.jerry
From uucp Fri Aug 14 09:31:36 1981 remote from pur-ee
NAharpo.407
Nnet.general
Npur-ee!cincy!duke!mhtsa!harpo!jerry
NWed Aug 12 10:42:36 1981
Nforgery
N
NI suppose Steve should know better than I do, but why couldn't
Na forger just uux (or execute directly)  rnews on a machine
Nwith the input indicating the item came from datamat!rumor.
NIn fact couldn't you drop it in almost anywhere in the net?
NPotentially the later can be detected because you will end up with
Npeculiar headers (e.g. the item
Nappears to have passed through a machine twice.)  A little
Nmore cleverness, and a better understanding of netnews might
Ncircumvent even that problem, and in any event the only thing
Nyou could learn would be the machine rnews was executed on.

SHAR_EOF
cat << \SHAR_EOF > rumor.mark
From uucp Sun Aug  9 15:54:14 1981 remote from pur-ee
NAucbvax.2534
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!mark
NWed Aug  5 08:47:18 1981
NThe truth about Unix
NI read your Unix flame with interest, but you seem to be
Nill informed about lots of things.  Obviously you are comparing
NV6 Unix with 3BSD, but you claim to be comparing "Unix" with
N"Berkeley Unix".  You credit Berkeley with things that are
Npart of V7 (getting rid of dsw, adding egrep and fgrep).
NI might compare your note with a message saying "don't go
Nout and buy a 1975 VW Rabbit - those are crummy cars because
Nthe 1979 Rabbit is better".  (No, I'm not complaining about
Nthe recent Rabbit note, this just happened to be a handy example).
NYou also claim that "Berkeley Unix is too big to fit ... on an 11/45".
NHogwash!  3BSD is a Vax distribution - it has a C compiler that
Ngenerates Vax object code, a kernel that knows the Vax memory management
Nand I/O conventions, and some other VAX specific things.  So are 4BSD
Nand 4.1BSD, which superceded 3BSD the same way V7 has superceeded V6.
NWe have lots of PDP-11's here at Berkeley, including 70's, a 45, and
Nseveral 40's.  Most of them run some version of Berkeley Unix.
NBigness is not important - we run vi 3.6 on a 40 in the virus lab.
NOf course, it is a different system than the one on the vax.
N"Berkeley Unix" is about as specific as "Chevrolet".
N
NYou also have to bear in mind that the various flavors of Unix have
Nevolved from one system years ago in Bell Labs.  In upgrading from
Nversion x to version x+1, issues of upward compatibility have to
Nbe taken into account.  If you changed /usr to /user, not only would
Nyou infuriate most of the users "What a pointless change!  Now I
Nhave to retype half my commands!" but you would break a large number
Nof programs that look for such places as /usr/spool/mail, /usr/dict/words,
Nand so on.  Things that are not obviously wrong and horrible tend
Nto get left alone.  (There are, unfortunately, exceptions.  index
Nand rindex are called strchr and strrchr in some versions of Unix.)

SHAR_EOF
cat << \SHAR_EOF > rumor.mark2
From uucp Mon Aug 10 22:18:44 1981 remote from pur-ee
NAucbvax.2598
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards
NMon Aug 10 12:23:20 1981
NEUNUCH for large machines
N>From csvax.mark@Berkeley Mon Aug 10 12:15:19 1981
NCare to back up your flame about big machines with some reasons?
NIt does run on a Vax, Univac 1100, Amdahl, 370, and 3B.
N
NBell invests lots of effort into Unix - about as much as the rest
Nof the world.  But their version doesn't get released.
N
N    Mark
N
N

SHAR_EOF
cat << \SHAR_EOF > rumor.mo
From uucp Fri Aug 14 11:40:30 1981 remote from pur-ee
NAucbvax.2628
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards
NTue Aug 11 11:41:44 1981
NFlaming Psychologists
N>From mo@LBL-UNIX Tue Aug 11 11:23:32 1981
NWell, you see what kind of stuff gets into DATAMATION.
NI don't understand these things: many of the criticisms
Nare right, but the facts are categorically wrong!  Unix
Ncould benefit from some "normalizaion" (the Software Tools
Nbenefitted greatly from having been written all at once, not
Nover the years), but the claim that Unix does not present
Na simple set of principles is the most incomprehensible
Nstatement he could have made!  That is ALL Unix does,
Nand that is precisely why he doesn't like it!  If he hates
Nit so much, why doesn't he go get an account on a TOPS-10 system
Nor since he is at UCSD, a UCSD PASCAL machine?
N    Well, enough of that.  I yield the floor to Lauren.
N    -Mike
N

SHAR_EOF
cat << \SHAR_EOF > rumor.nowicki
From uucp Fri Aug 14 11:57:07 1981 remote from pur-ee
NAucbvax.2660
Nfa.unix-wizards
Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards
NWed Aug 12 11:44:04 1981
NMisunderstanding about Unix.....
N>From Nowicki@PARC-MAXC Wed Aug 12 11:35:03 1981
NI would like to make a few comments on Donald Norman paper on "The
NTruth About Unix".  The arguments for Consistency, Simple Models, and
NMnemonic Aids should all be Motherhood, even though many system
Ndesigners continue to ignore them. (If you want consistent
Nabbreviations you can use RSX-11M for a while where all commands are
Nthree letters; then you'll appreciate Unix.)
N
NThe major mistake that is made, however, is failing to consider the
Npossible multiple levels of abstraction.  For example, the title says
N"The user interface is horrid", but in reality every level of
Nabstraction has a "user interface," namely its interface to the next
Nhigher level.  The motto of the Unix was not "let the user beware," but
Nrather, "make the primitives simple but powerful, so as much as
Npossible can be done at higher levels".  With his arguments, you could
Nsay that all man-computer communication is doomed to failure because it
Nuses only ones and zeros, which are not very mnemonic.  The real
Nproblem is that an appropriate level for a systems programmer is not
Nappropriate for casual end users.  This conclusion is hinted at near
Nthe end of the paper, but it means that the paper should not be a
Ncriticism of Unix itself, but rather a criticism of how people use
NUnix.
N
NThe point that someone reading only the first few paragraphs of the
Npaper can miss is that the primitives in Unix CAN be either easily
Nreplaced or encapsulated, while almost no other systems provide this
Ncapability.  As an example, two Stanford students have implemented a
NTOPS-20 style command interpreter for Unix.  It has arbitrary
Nabbreviations, <escape> command completion, the question-mark help
Nfacility, and a delete-undelete-expunge facility.  Version numbers for
Nbackup files are implemented with a simple suffix to the file name.
N
NThe real shame is that the Unix users themselves are forced to make the
Nsystem as distributed from Western more humane, and thus every wheel
Ngets reinvented many times.  Luckily groups like Berkeley and Usenix
Nare trying to help this situation, but as indicated progress is very
Nslow.
N
N    -- Bill
N
N
N
SHAR_EOF
cat << \SHAR_EOF > rumor.swd
From uucp Fri Aug 14 11:37:48 1981 remote from pur-ee
NAduke.943
Nnet.general
Npur-ee!cincy!duke!swd
NThu Aug 13 09:23:28 1981
Nmore rumor rumors
NSome random thoughts on the datamat!rumor article.
N
N1) it did not enter the net at utzoo by having someone
N   there run rnews to submit it.  If they had, utzoo
N   would have seen the article.  If it entered at decvax,
N   it would not have been sent to utzoo -- the anti loop
N   code in news will not send an article to any system
N   on the return path.  Since the article did show up at
N   decvax, it entered the net there.
N
N2) what probably happened is that someone on the west coast
N   (Note the PDT in the date line) created the article
N   and ran  uux - decvax!rnews <fake article.
N
N3) there is no way to prevent this (short of an elaborate
N   public key encryption scheme).

SHAR_EOF
#    End of shell archive
exit 0

-----------------------------

From: Rich Kulawiec <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 02:07:48 GMT
Sender: [e-mail]
Nntp-Posting-Host: gynko.circ.upenn.edu
To:       [e-mail]

In article <[e-mail]> [e-mail] (Jurgen Botz) writes:
>I agree.  Heh... Not only are those who keep pronouncing the death of
>Unix dead wrong, but their credibility is starting to rot.

In that same vein, from time to time, I recall with great satisfaction
a conversation I had with one of the bigwigs at Forth, Inc. back in 1982.
This person explained to me in glorious detail why Unix was just a passing
thing, and how in a couple of years we'd all be writing Forth and running
their monitor-like OS, and ...

I think of this everytime I read another vaporware announcement
concerning Windows NT.  Unix outlasted CP/M and VMS and RSTS and
AOS and <add your favorite long-obsolete operating system here>; I suspect
that it will outlast Windows NT as well.  (Although Plan 9 could
give it a serious run for the money in a few years.)

---Rsk

-----------------------------

From: Bill Vermillion <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 03:05:29 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> [e-mail] (Bryan S. So) writes:

>>   To me, some problems like "cat a b > b" are obviously undesirable
>>   designs and still unsolved after more than a decade.

>It has been solved. There are at least two solutions:
>    1) Educate the user. After all the system did exactly what
>        the user told it to do.
>    2) in csh/tcsh, do "set noclobber"
>
>grymoire% set noclobber
>grymoire% touch a b
>grymoire% cat a b >b
>b: File exists.

And some of the lastest bourne shells also have fixed it.  In sysv.3.2
from Esix if I type

cat a b > b    I get this result

cat: input/output files 'b' identical

So after a decade these have been solved.


--
Bill Vermillion - [e-mail]  [e-mail]
                - [e-mail]
                - ..!{peora|tous|tarpit}!bilver!bill

-----------------------------

From: David Barr <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 03:16:11 GMT
Sender: Usenet <[e-mail]>
To:       [e-mail]

In article <[e-mail]> [e-mail] (Michael Lemke) writes:
>Well, fixing typos is neat but it is not the essential problem.  My
>main complaint about Unix on the user interface level is that there is
>no command line interpreter.  What I mean is that after the shell munged
>your command line it is *completely* up to the program to interpret the
>command line and there is no system function available to parse even
>these `standard' options.

You mean like getopt(3)?

>Some programs use one letter chinese (you
>know, one character per word) and others (eg, find) use words (-print
>-name).  And the real problem then starts when -l changes its meaning
>from command to command, some commands need spaces between the option
>and the argument, others don't, some take both, yech.  This would all be
>solved if there were *one* system function that is used by all programs
>instead of having every program duplicate more or less the same
>functionality with different success.

You mean like getopt(3)?   There is one function, it's just the people
don't always choose to use it.  I don't find this to be a Bad Thing.
getopt(3) is too limiting in some cases, and it is overkill in others.
Yes, this 'dd if=filename conv=ascii' is for the birds, and the author
should have been shot for doing it this way, but that's not a reason
to fault UNIX.

>And it would be great if you
>could abbreviate commands (command completion of some shells it neat
>but why is it neccessary in the first place?) and options (no need for
>dynamic chinese anymore).
>
>>I agree with Scott: There is no good reason that command shells shouldn't make
>>more of an effort to understand the user.
>
>Computer:  Calculate the weather forecast for Sunday, Nov 15!

Why would i want to type all that out when i can just say:

% weather nov 15

--Dave
--
System Administrator, Population Research Institute    [e-mail]

-----------------------------

From: Andy Newman <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 04:32:46 GMT
Sender: [e-mail]
To:       [e-mail]

[e-mail] (Mike Stefanik) writes:
>In an article, [e-mail] (Boyd Roberts) writes:
>>The real problem, as Rob has so eloquently put it:
>>
>>    ``Not only is UNIX dead, it's starting to smell really bad.''
>
>I find it amazing that people, apparently in pursuit of some small amount of
>enjoyment, spend their time proclaiming the death of UNIX. This sort of thing
>is really beginning to take on the flavor of the apocalyptic doomsayers (you
>know the type ... they run about the streets wearing dirty plaid suits bellowing
>"Repent Now, For the End is Near!").
>
>I have heard UNIX to be proclaimed dead and buried for years now. I have no
>doubt that there are those who would *like* UNIX to be dead, but desire alone
>does not make a thing so. Microsoft is a good case in point, I suppose.
>
>So, Boyd, if UNIX really is dead, where is the funeral? I would so enjoy
>paying my last respects ...
>
>Oh, and by the way, I do assume then that you are using VMS, DOS, or perhaps a
>beta version of Windows NT?  You wouldn't be caught *dead* using UNIX, am I
>right? :-)
>

Calm down! What Rob Pike (and Boyd) mean is that its lost its appeal.
Its lost the elegance it once had. The requirements (and environment)
for an OS have changed a lot but the overall design hasn't. People
have grafted all sorts of things on the side (have a look at the
recent offerings from USL - makes MVS look like CP/M!) and pushed the
OS into areas where it wasn't meant to go (i.e. becoming a distributed
system). And it doesn't cope too well. Its bigger and slower than
ever. You don't get a distributed system from sticking something on the
side of a non-distributed system. You need to build the system
with distribution in mind. Now that doesn't mean that there's anything
else (available to the masses) that is any better (by "better" I'm
talking about things I want - I'm a programmer and UNIX *is*
user-friendly to me).

--
Andy Newman ([e-mail])

-----------------------------

From: "Felix S. Gallo" <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 07:14:11 GMT
Sender: "Felix S. Gallo" <[e-mail]>
Followup-To: comp.unix.wizards
To:       [e-mail]

[e-mail] (Bryan S. So) writes:

>Concerning "cat a b > b", [e-mail] writes:
>
>>It has been solved. There are at least two solutions:
>>    1) Educate the user. After all the system did exactly what
>>        the user told it to do.
>>    2) in csh/tcsh, do "set noclobber"

> [these are not solutions, because]
>
>1. We should assume some stubborn users cannot be educated.  I
>   claim without proof such users exist.

Users which cannot grasp the concept of files being overwritten will
not be able to grasp the concept of output redirection.  Such users,
if they do exist, should not be catered to.  Let evolution work its
course.

>Bryan


--
 ----------------------------------------------------------------------------
Felix Sebastian Gallo                              [e-mail]
 ----------------------------------------------------------------------------

-----------------------------

From: Arne Henrik Juul <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 07:36:32 GMT
Sender: NetNews Administrator <[e-mail]>
To:       [e-mail]

In article <[e-mail]>
 [e-mail] (Bryan S. So) writes:

   To me, some problems like "cat a b > b" are obviously undesirable
   designs and still unsolved after more than a decade.

Well, you can make this error in other operating systems too, here's VMS:
$ define SYS$OUTPUT myfile
$ type myfile,anotherfile

Of course, VMS keeps every version of every file I have ever made
(assuming I'm a naive user who haven't heard of purge), but then
I probably won't know how to get the old version back, either.

Probably ANY decent OS/UI will make it possible to make exactly this
mistake. To put it another way: If you add features to make it
impossible to make this kind of mistake, it won't be a good OS/UI
anymore.

It's just that it is much easier to do it in Unix. Remember: Unix
was designed to make it possible to do smart things easily, it was
NOT designed to make it hard to do dumb things.

I can imagine it will be impossible to make this mistake in
Windows/NT, but I fully expect that it will be impossible to
concatenate two files in Windows/NT too.

-- Arne H. Juul, [e-mail]

-----------------------------

From: Arlie Davis <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 09:00:37 GMT
Sender: Netnews <[e-mail]>
Nntp-Posting-Host: starbase.spd.louisville.edu
To:       [e-mail]

In <[e-mail]> [e-mail] (Bill Vermillion) writes:

> And some of the lastest bourne shells also have fixed it.  In sysv.3.2
> from Esix if I type

> cat a b > b    I get this result

> cat: input/output files 'b' identical

> So after a decade these have been solved.

This was a fix to cat, not any of the shells.  And b still gets clobbered.
It *is* an improvement, though, and mine acts the same way.

I responded in email to Bryan So that a decent solution is a (hypothetical
but terribly simple) program called "buffer" would reads its stdin until EOF,
then opens and writes all to the filename in argv[1].  So, "cat a b > b"
becomes "cat a b | buffer b".  He seemed to like the suggestion.

--
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null

-----------------------------

From: der Mouse <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 09:19:14 GMT
Followup-To: comp.unix.wizards,comp.unix.shell
To:       [e-mail]

[ I am removing comp.unix.misc from followups.  It's posted to two
  other comp.unix.* groups; comp.unix.misc is inappropriate. ]

In article <[e-mail]>, [e-mail] (Scott Beckstead) writes:
> In article <[e-mail]> Arlie Davis <[e-mail]> writes:
[stuff we've all seen plenty of times already]

> I agree an experienced user should be able to recognize and avoid the
> problems above.  What's wrong with the shell catching such obvious
> errors and either reporting them or taking other appropriate action
> (ie correcting them).

(Is that an unfinished sentence, or a question with no question mark?
Given context, I'll assume the latter.)  What's wrong with it?  First
of all, it's impossible.  Specifically,

    cat a b > b

How is the shell supposed to know that cat is going to interpret its
arguments as filenames, and what's more, output the contents of those
files?  Consider instead "echo a b > b".[%]

    rm -filename

How is the shell supposed to know whether the user intended that
argument as a filename to remove or an option to rm?  In at least some
cases (eg, -i) only the user knows.

    mail someone < a.out

How is the shell supposed to know that mail takes only printable text?
It can't.  Perhaps this version of mail is a new whizbang mailer in
test that does take binary files....

In all of these cases, the shell has to know quite a lot about the
semantics of the program being run.  It cannot know all about every
program, and I submit that partially protecting users from themselves
is worse than not doing it at all.

Besides all that, these aren't always mistakes.  I once wanted to fill
up a filesystem in a hurry, so I copied /vmunix to foo and then did
"cat foo >> foo".  I was *extremely* annoyed when cat said something
along the lines of "input foo is output" and refused to run.  I had to
waste a pipe and do "cat foo | cat >> foo", and then realized that the
extra copies involved in the pipe were slowing down the operation and
switched to using dd, which mercifully had not been broken by some
overzealous fool trying to keep people from shooting themselves in the
foot.

> I realize that this will get me screamed at by all you guru types
> that advocate that all shell users be rocket scientists or why bother
> using a computer anyway.

I don't see what rockets have to do with it.  *deadpan look*

No, you misunderstand.  Not "why bother using a computer anyway" but
"why use a system which wasn't designed for you and isn't suited to
you".  UNIX was built by hackers for hackers, and hackers seem to like
it just fine.  If you don't like it, by all means, don't use it.

> However I see no reason NOT to research the subject.  If UNIX could
> be made more user friendly by modifying the shell it might gain more
> acceptance in the general microcomputer market place, GUIs not
> withstanding.

Yes, it might.  So what?  Is "acceptance in the general microcomputer
market place" something we wish for UNIX?  If it means dumbing down the
interface until people no longer have enough rope to hang themselves,
well, you can if you want, but I'll keep using what I've got.

[%] Yes, I know there are shells with echo built in.  The point I'm
    trying to make is still valid.

                    der Mouse

                [e-mail]

-----------------------------

From: Mark Evans <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 10:47:31 GMT
Sender: Usenet administrator <[e-mail]>
Nntp-Posting-Host: uhura
To:       [e-mail]

[e-mail] (Michael Lemke) writes:
: In article <[e-mail]> [e-mail] (Eric Eide) writes:
: >Scott Beckstead ([e-mail]) writes:
: >
: >
: >I know of somebody who is doing research in this direction: me.  As part of my
: >Masters degree I am modifying the C shell to be more tolerant of errors, both
: >errors in syntax (e.g., typos) and semantics (e.g., inappropriate command line
: >arguments).  My new shell keeps track of the user's command history in order to
: >make accurate corrections.
: >
: >I have no hopes to solve all of the shell user interface problems, but I do
: >hope to solve most of the common errors.  Just by fixing obvious typos my shell
: >can fix 90% of the command line errors that I (and most people) make on a daily
: >basis.
: >
:
: Well, fixing typos is neat but it is not the essential problem.  My
: main complaint about Unix on the user interface level is that there is
: no command line interpreter.  What I mean is that after the shell munged
: your command line it is *completely* up to the program to interpret the
: command line and there is no system function available to parse even
: these `standard' options.  Some programs use one letter chinese (you
: know, one character per word) and others (eg, find) use words (-print
: -name).  And the real problem then starts when -l changes its meaning
: from command to command, some commands need spaces between the option
: and the argument, others don't, some take both, yech.  This would all be
: solved if there were *one* system function that is used by all programs
: instead of having every program duplicate more or less the same
: functionality with different success.  And it would be great if you
: could abbreviate commands (command completion of some shells it neat
: but why is it neccessary in the first place?) and options (no need for
: dynamic chinese anymore).

Could you say what operating system has this feature.
(DOS dos the same, what does VMS do?)
Also how the programmer is ment to use it.
Does this belong in the operating system (thus resulting in command line
options sitting in the PCB, yuck!! add a new 'standard' option rebuild
the system)
:
: >I agree with Scott: There is no good reason that command shells shouldn't make
: >more of an effort to understand the user.
:
: Computer:  Calculate the weather forecast for Sunday, Nov 15!
:
: Yes, I would appreciate this... :-)
:
: >Shells obviously can't divine the
: >user's intentions in all cases, but that's not a good argument for failing to
: >understand the user's intentions in *all* cases.
: >
:
: Does AI work now?
--
 -------------------------------------------------------------------------
Mark Evans                                   |[e-mail]
+(44) 21 565 1979 (Home)                     |[e-mail]
+(44) 21 359 6531 x4039 (Office)             |

-----------------------------

From: Bruce Barnett <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 14:34:17 GMT
Sender: Required for NNTP <[e-mail]>
Nntp-Posting-Host: grymoire.crd.ge.com
To:       [e-mail]

In article <[e-mail]> [e-mail] (Michael Lemke) writes:
>   Well, fixing typos is neat but it is not the essential problem.  My
>   main complaint about Unix on the user interface level is that there is
>   no command line interpreter.  What I mean is that after the shell munged
>   your command line it is *completely* up to the program to interpret the
>   command line and there is no system function available to parse even
>   these `standard' options.

Some look at this as an advantage. You are probably complaining about
the inability to perform
    rename *.old *.new

The point of the shell is to prevent every program from having to
parse
    ~bill/$DIR/`prog`/*[0-9]?.{xxx,yyy}

It becomes TRIVIAL to write a new shell utility. In fact many are just
more shell utilities.

If you don't like ls, write your own version. It only takes a few seconds.
If you don't like the fact the shell expands all of the metacharacters
automatically, just turn it off. In csh, do a

    set noglob

then you can write a program called "rename", and let it parse the
arguments itself. People found out that the purpose of the shell is to
expand meta-characters, just so that the shell commands don't have to
bother. The programs also don't have to worry about I/O redirection. I
remember writing programs, and having to change the source of the
program when I wanted a printout vs.  output to the terminal. What a
waste of time!


It sounds like most of your problem is due to the large number of UNIX
utilities. How many does DOS have? If you don't like all of the
old/strange utilities, delete them or don't use them. It's not many
operating systems that give you (Hmm. time to write a new shell
command.... tic, tic, Done) ...

    find /usr/ucb /usr/bin -type f -print | wc -l

319 different commands to the shell.
That's a small number. I actually have 2033 shell commands now.

Hey, if I only have 30 commands, it would be trivial to make them similar.
--
Bruce Barnett <[e-mail]> uunet!crdgw1!barnett

-----------------------------

From: Jurgen Botz <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 15:10:25 GMT
Sender: USENET News System <[e-mail]>
To:       [e-mail]

In article <[e-mail]> [e-mail] (Eric Eide) writes:
>I know of somebody who is doing research in this direction: me.  As part of my
>Masters degree I am modifying the C shell to be more tolerant of errors, both
>errors in syntax (e.g., typos) and semantics (e.g., inappropriate command line
>arguments).  My new shell keeps track of the user's command history in order to
>make accurate corrections.

Without wanting to make a judgement about the viability of the basic
research underlying such a project, why are you starting with the C
shell?  If I wanted to create a user-interface that could deal with
errors and ambiguities introduced by the user I would first make sure
that the software itself isn't full of errors and ambiguities... i.e.,
I sure as hell wouldn't use the C shell.
--
Jurgen Botz                  |   Internet: [e-mail]
Academic Systems Consultant  |     Bitnet: [e-mail]
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629

-----------------------------

From: Bruce Barnett <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 15:30:27 GMT
Sender: Required for NNTP <[e-mail]>
Nntp-Posting-Host: grymoire.crd.ge.com
To:       [e-mail]

In article <[e-mail]> [e-mail] (Bryan S. So) writes:
>   I propose a real solution to this problem.  Change the internal
>   policy of UNIX, so that when any file is used as both input and
>   output, like

>       cat a b > a
>   or     cat a b > b

>UNIX should read and buffer all input before opening the output
>with "w".

Maybe. Perhaps the command was a typo, and the user didn't want
to change "b". Perhaps UNIX should use version numbers, like VMS. That
also solves both problems. Maybe UNIX should have an "undo" facility
for all file operations. Maybe cat should be able to read "b" while
it's getting larger (i.e. during the shell command). What about

    tail -f b > b

Go back to "cat a b >b". Given three different responses:

    1. deleting forever the contents of b
    2. giving the user an error message
    3. prepending a to b

I argue that #2 is the best choice.

Number 1 is bad. Number 2 is safe. Number 3 may or may not be what the
user wanted to do. Given that it is not clear what the user expects
"cat a b >b" to do, I believe a better answer is to simply tell the
user that this might be an error on their part. Anyone who understands
the implications of "cat a b >b" ought to be able to understand how to
get around it. The only time it is a REAL problem is when the size of
files a + b are greater than the amount of free disk space. At this
time, the user should be VERY CAREFUL about the implications of the
operation.

Suppose the disk fills up while the new "b" is being created. What
happens afterwards? Is the new "b" deleted? Or the old one?

--
Bruce Barnett <[e-mail]> uunet!crdgw1!barnett

-----------------------------

From: peter da silva <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 18:24:20 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Leslie Mikesell) writes:
> In article <[e-mail]> [e-mail] (peter da silva) writes:
> >>     Sending binary file should be uuencoded first.

> >Nope. It should say "mail: Standard input contains NULL characters." And
> >abort.

> I disagree on this one.  It should just work unless you are of the opinion
> that computers should not handle arbitrary binary data.

No, I am of the opinion that if you want to send binary data you should use
a program called "send", rather than overloading the semantics on mail. In
principle you have no idea what the recipient will be able to deal with, and
in the general case you have no way to know. If your default mail program
just arbitrarily makes assumptions (in the absence of explicit command line
options or an interactive exchange) about the capabilities of the recipient
and mail transfer tools (who knows, they could be on Fido, or Compuserve)
then you WILL burn people.

> SysVr4 gets
> this one right by checking the content before trying to display it but
> not before delivering it to the right place.

I'll be sure to keep that in mind the first time some garbaged binary data
ends up in my mailbox.

In the meantime, the following should be a 40 line shell script:

NAME

  send -- send arbitrary file using encapsulation over mail

SYNOPSIS

  send recipient options+files

OPTIONS

  -u Succeeding files shoul be uuencoded

  -a Succeeding files should be sent using atob

  -b Succeeding files should be sent using binhex

  -c Succeeding files should be sent as a cpio archive

  -s files should be sent in "shar" format

  -m files should be sent using "mime" format (default)

  ...
--
Peter da Silva / 77487-5012 USA / [phone]
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?

-----------------------------

From: Rich Kulawiec <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 03:20:51 GMT
Sender: [e-mail]
Followup-To: comp.unix.wizards
Nntp-Posting-Host: gynko.circ.upenn.edu
To:       [e-mail]

In article <[e-mail]> [e-mail] (Ben Ketteridge) writes:
>From what you say about each of Bryan So cases of command-line problems, I take
>it to mean that you think that it is _entirely_ the users' responsibility to
>check that they don't type incorrect commands?

Absolutely.  It's a computer, not a mind reader: it will do exactly what
you tell it to do.  If you use a computer, you should be prepared to face
this basic tenet.  (Until, of course, you have a machine available that
can intuit your intentions regardless of what you type.)

To put it another way: I often tell beginning users that they will
be held personally responsible for the consequences of every command
the run.  This does seem to inspire a degree of careful attention on their
part, but it usually takes it least one "rm *" or "cat > foo" episode
to drive the point home.

---Rsk

-----------------------------

From: "Bryan S. So" <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 06:00:56 GMT
Sender: The News <[e-mail]>
To:       [e-mail]

In article <[e-mail]> [e-mail] (Jurgen Botz) writes:
>In article <[e-mail]> [e-mail] (Eric Eide) writes:
)>I know of somebody who is doing research in this direction: me.  As part of my
)>Masters degree I am modifying the C shell to be more tolerant of errors, both
)>errors in syntax (e.g., typos) and semantics (e.g., inappropriate command line
)>arguments).  My new shell keeps track of the user's command history in order to
)>make accurate corrections.
)
)Without wanting to make a judgement about the viability of the basic
)research underlying such a project, why are you starting with the C
)shell?  If I wanted to create a user-interface that could deal with
)errors and ambiguities introduced by the user I would first make sure
)that the software itself isn't full of errors and ambiguities... i.e.,
)I sure as hell wouldn't use the C shell.

 PROBABLY because compatibility is a big issue.  I think the major
 reason why Don Norman's decade old complaints aren't fixed yet is
 to retaining compatibility.

Bryan

-----------------------------

From: der Mouse <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 10:39:25 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Bryan S. So) writes:

> [quotes and stuff about "cat a b > b"]

> I propose a real solution to this problem.  Change the internal
> policy of UNIX, so that when any file is used as both input and
> output, like [this] UNIX should read and buffer all input before
> opening the output with "w".

("w"?)  You are ignoring an important issue here: doing this would mean
a drastic redesign of the fundamental paradigm.  This is because the
shell doesn't know that the a and b in the argument list are input
filenames, and by the time cat is started, the output redirection has
already taken place.  What you propose requires changing one or both of
those, and in either case, you have lost the clean division between
shell and program that has proven so useful.  (Okay, it's not quite as
clean as it used to be.  It's sure lots more so than in, say, VMS.)

                    der Mouse

                [e-mail]

-----------------------------

From: der Mouse <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 10:42:09 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Arlie Davis) writes:

> I responded in email to Bryan So that a decent solution is a
> (hypothetical but terribly simple) program called "buffer" would
> reads its stdin until EOF, then opens and writes all to the filename
> in argv[1].  So, "cat a b > b" becomes "cat a b | buffer b".

Not hypothetical at all.  I wrote it some time ago, though I called it
"delay" rather than "buffer".  And yes, it is terribly simple - the
hardest part is deciding where to buffer the data.

                    der Mouse

                [e-mail]

-----------------------------

From: Troy Frericks <[e-mail]>
Subject: Re: >>TAR file on tape distroyed, are files recoverable?<<
Date: 11 Nov 92 22:23:08 GMT
Sender: [e-mail]
Nntp-Posting-Host: marx
To:       [e-mail]

In article <[e-mail]> [e-mail] (Troy Frericks) writes:
>I have a tape that contained a large 'tar' file.  The data is not
>replaceable.  The data that is needed is at the end of the tar
>file, but it is inaccessable because the wrong parameter was
>passed to tar when attempting to retrieve it.  The 'c' for
>create, rather than 'x' for eXtract was passed, which caused
>tar to write a tiny tar file over the beginning of the
>larger one.
>
>Any hints on how to retrieve files from a large tar file once
>the beginning of the tar file has been distroyed?
>
>-
>Troy Frericks                      Internet: [e-mail]
>Microware Systems Corporation          UUCP: uunet!mcrware!troyf
>1900 NW 114th St                      Phone: [phone]
>Des Moines, IA 50325-7077               Fax: [phone]

Thanks to all who helped me out on this -- espically uunet!iti.gov.sg!ram (Ram)
What I ended up doing was

- dd'ed the contents of first meg of tape to a disk file
- hexdump the file looking for valid data - noted offset of the first valid
    file name (offset was 10753)
- dd if=device bs=1024 | tail +10753c | tar -xvf -
    which got the info from tape | skipped over the bad part | and
    let tar process the good part.

-
Troy Frericks                      Internet: [e-mail]
Microware Systems Corporation          UUCP: uunet!mcrware!troyf
1900 NW 114th St                      Phone: [phone]
Des Moines, IA 50325-7077               Fax: [phone]

-----------------------------

From: David Baboulene DND3 <[e-mail]>
Subject: SCCS ID Keywords problem
Date: 12 Nov 92 08:28:17 GMT
Sender: [e-mail]
To:       [e-mail]


Hi Chaps/Chappettes,

We have a couple of source and header files which include
lines like the following:

#define GRG "%Y%S%d%M%"

The problem is that an SCCS get <filename> reads the %Y%S%d%M%
as ID keywords (which is not what they are intended to be) and
expands it to the date, time, version id etc. thereby turning the
line into garbage.

Does anyone know a way of supressing keyword expansion under SCCS?
I know I could use sccs get -e <filename>, keeping the file out
for edit at all times, and I am doing this as a quick fix, but need
a way of supressing the keyword expansion to cure the problem
properly.

Thanking you in advance of any help you can give,

Cheers,


David Baboulene ([e-mail])

British Telecom Research Labs.      o  o
Suffolk,                              >
England.                              .


            -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

                Love thy neighbour; tune thy piano

-----------------------------

From: Alan Wright <[e-mail]>
Subject: Re: RPCGEN
Date: 12 Nov 92 13:58:33 GMT
Sender: [e-mail]
To:       [e-mail]

In article <[e-mail]>,
[e-mail] (Mike Leibensperger) writes:
|>
|> HP/Apollo's Network Interface Definition Language (NIDL) used to
|> generate either Pascal or C language stubs.  It has since been
|> transmogrified into just plain IDL, the RPC interface language for
|> OSF's DCE RPC.  I'm not sure if it still generates Pascal stubs or
|> not.
|>

Not as far as I'm aware. If OSF's DCE IDL can produce
Pascal then it's an undocumented feature.

Alan.

 --------------------------------------------
[e-mail] (Alan Wright)
BT, Software Engineering Centre, Glasgow, UK
 --------------------------------------------

-----------------------------

From: Mark Bush <[e-mail]>
Subject: Re: Any TeX (compilation) Gurus out there?
Keywords: TeX, make
Date: 12 Nov 92 15:38:16 GMT
Originator: [e-mail]
To:       [e-mail]

In article <[e-mail]> [e-mail] (Eric Parson) writes:
#get MF to process the plain.mf file, but in the 'Makefile' command file,
#it displays the line:
#    inimf plain; input modes; dump
#Well, it gets through the inimf, but fails the input.  Now there aren't that
#many copies of files with the name 'modes' in them (two to be precise, and
#one is amsmodes.mf), thus I thought that moving a copy of modes.mf from the
#input directory would solve my problem.  It didn't.  Now I don't know what
#else to do.

In what manner didn't it?

From README.WEB2C:

 ------------------------------------
10. `make bases' to make the base files for Metafont that you want.
    Besides the variable `bases' in ./Makefile, you may also want to
    change the variable `localmodes'.  It is also a good idea to try to
 ------------------------------------

and from ./Makefile:

 ------------------------------------
# The name of the file that defines your local devices, for use with
# Metafont.  (Only relevant during `make bases'.)  I urge you to get the
# file `modes.mf', which defines all known modes, plus useful
# definitions for all fonts.  It's available from ftp.cs.umb.edu
# [192.12.26.23] as pub/tex/modes.mf, among other places.
localmodes=modes
 ------------------------------------

You should place a copy of this into the area you have defined in lib/site.h
as the value of MFINPUTS.

Mark

-----------------------------

From: Soren M Burkhart <[e-mail]>
Subject: Problem with Window to Window commands.... HELP!
Date: 12 Nov 92 15:59:09 GMT
To:       [e-mail]


  Hi, I am working on a PUMA robot using VALII, and currently trying to
talk to the monitor program is real pain!  We have to use a program called
ff2 which issues commands from my c code via file flagging.  This is
running on a Sun 3 and it is excessively slow.  My question is, is it possible
to issue a command to another tty that you currently have open?  Excuse my
ignorance, but I have tried sending commands to the /dev/ttyXX file , but  I
see that all it does is display on the screen.  All three programs (my code,
val II , and ff2) have their own window.  I need this to work faster because
we will be using the PUMA robot to play air-hockey against us... well
hopefully! :>
  I appreciate any help or hints on how to fix this situation.


   thanks,

      Soren


**************************************************************************

  Soren Burkhart
  Purdue University
  AI & Robotics
  EMAIL: [e-mail]

-----------------------------

From: Alun <[e-mail]>
Subject: Closing ends of pipe().
Date: 12 Nov 92 16:28:05 GMT
Sender: news user <[e-mail]>
Nntp-Posting-Host: cc_sysh
To:       [e-mail]

I have a program that loops x number of times. Forks of a child and uses pipe()
and dup2() to get the output of the child to the parent. My problem is
in the program I have to use the pipe() function 'x' times and then fdopen() the
read end 'x' times. I want to use the FILE* functionality.

What I would like to do is just be able to reopen the write end in the parent
or is there anyway other of getting the read end to return EOF when there
is still a write end open ?? So I can put the pipe() and fdopen() code
outside of the loop.

Cheers

    -Alun

--
A.Champion                |  That's an interesting point, in the sense of
([e-mail])  |    being very not interesting at all. - The Liar

-----------------------------

From: "neal.l.leitner" <[e-mail]>
Subject: TTYDEFS Help!
Date: 12 Nov 92 21:15:52 GMT
Sender: [e-mail]
To:       [e-mail]

Nobody was able to help me out with this problem, so I am turning to
this group.

Anyone know if there is a size limitation to the /etc/ttydefs file???

I am using Unix SysV rel 4.0.2.1.  My ttydefs file, after adding some
entries is 134 lines long.  Using the pmadm command to configure a port,
the port will not configure properly.  The term entry I want to use in
the ttydefs file is on line 124, so I moved it to the top of the ttydefs
file and configured the port and it configured ok.  After playing around
a while line 115 of the ttydefs file seem to be the limit.  The port
would configure with the entry on line 115, but not 116.  Anyone
else have any experience with this????

Neal Leitner
 ..att!emdbl1!nll

-----------------------------

From: der Mouse <[e-mail]>
Subject: Re: HELP! problem with tar PC <-> SUN
Date: 12 Nov 92 21:27:14 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Francisco X DeJesus) writes:

> [transferring files with tar between SunOS 4.1.2 and "a PC running
> Unix" (which dejesus says "refers to trying this with SCO Unix,
> Interactive Unix, and Intel Unix").

> Here's the problem: [...] [i]f a tape is written on the Sun with a
> blocking fator of 2, the PC reads it as a blocking factor of 20.
> [T]his is where the *REAL* problem comes in: [t]he client specifies
> that the "tar" command *HAS* to be used _WITHOUT_ telling it a
> specific blocking factor on either end [...].

Comes a point where you have to tell the client "I'm sorry, you're
being too stupid.  If you insist on that go find someone else to do
it.".  IMO this is pretty close to the line where that begins to be
called for.

> So... any ideas?  Please, we are wide open to suggestions.  ANY
> possibilities will be explored... a different tape driver, another PC
> Unix version, rebuilding tar on the PC (if we can get the sources)...
> anything goes.

In that case, why not just pick up any of the good free tars and build
it on one or both ends?  In that case, if it turns out to be a
system-level bug (ie, tar is doing its best and the system is mangling
things), you can patch the source to act as if it had the b option even
when it doesn't.  (Where are these tars?  At least one of them is
somewhere on uunet, and I wrote another one....)

                    der Mouse

                [e-mail]

-----------------------------

From: Dave Eisen <[e-mail]>
Subject: Re: HELP! problem with tar PC <-> SUN
Date: 12 Nov 92 23:48:22 GMT
Sender: Mr News <[e-mail]>
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Francisco X DeJesus) writes:

> Here's the problem: [...] [i]f a tape is written on the Sun with a
> blocking fator of 2, the PC reads it as a blocking factor of 20.
> [T]his is where the *REAL* problem comes in: [t]he client specifies
> that the "tar" command *HAS* to be used _WITHOUT_ telling it a
> specific blocking factor on either end [...].
>

I don't know about Interactive or Intel UNIX for the PC, but you
can solve this problem easily enough on SCO Xenix. Tar looks for
information about the source device in the file /etc/default/tar.
So if you set up an entry for a device named /dev/suntape with the
appropriate blocking factor, then the user can just run tar xv6
if this is entry 6 or tar xv if this is the default entry.

On the other systems, you can accomplish much the same thing by using
the usual trick of making tar a shell script that just sets up the
command line and calls /bin/tar.real with the appropriate parameters.

This probably still won't make him happy. He'll want to read tapes
that were created with a blocking factor of 20 using a blocking
factor of 20 and tapes that were created with a blocking factor of
2 using a blocking factor of 2. In other words, he wants tar to
be clairvoyent. If this is the case, all you can do is tell him that
he wants something impossible and hope you don't lose the business.


--
Dave Eisen                               Sequoia Peripherals: [phone]
[e-mail]              Home:                [phone]
       There's something in my library to offend everybody.
          --- Washington Coalition Against Censorship

-----------------------------

From: Daniel Packman <[e-mail]>
Subject: Verbose errors on demand - was Re: The Problem with UNIX
Date: 12 Nov 92 23:26:49 GMT
Sender: USENET Maintenance <[e-mail]>
To:       [e-mail]

In article <[e-mail]> [e-mail] (Karl Anderson) writes:
>
>Is there any reason why there can't be another stream for more
>user-friendly messages?  We have stdin and stderr, why can't there be
>a standard verbose stream as well?  Experienced users could just
>direct it to /dev/null , or, to save cpu time, could have a flag that
>would disable it altogether.
>
I see no reason for the complexity of another stream... just have an
environment variable "VERBOSE" which, when defined, would give reams
of nasty commentary, ring terminal bells, and blow terminal whistles.

--
Dan Packman     NCAR                             INTERNET: [e-mail]
[phone]  P.O. Box 3000
                Boulder, CO  80307-3000        NSI/DECNET: 9583::PACK

-----------------------------

From: David B Stewart <[e-mail]>
Subject: RESULT: comp.arch.bus.vmebus passes 227:19
Keywords: VMEbus
Date: 13 Nov 92 10:16:08 GMT
Sender: David C Lawrence <[e-mail]>
Followup-To: news.groups
Approved: [e-mail]
To:       [e-mail]

Below is the result of votes received in the comp.arch.bus.vmebus
new group vote as of 00:01 EST  11 November 1992.

Vote Tabulation:

    258 votes received
     12 simple duplicates reduced to one each

     19 no
    227 yes
    -------------
    246 total

    227 yes
      -  19 no
    -------------
    208 margin  (more than 100 more yes than no!)

    227 / 246 = 0.920 = 92.0%  (more than 2/3 [67%] in favor!)

Having met the declared criteria, it appears that the vote for
comp.arch.bus.vmebus has passed.

The list of voters, grouped by how they voted, and sorted by the "From:" line
of their email, appears below.  If there are no substantial changes to the
recorded votes within the 5 days from the posting of this article, the group
creation message will be issued by David Lawrence (tale@uunet).

During the vote, 4 ambiguous ballots were received (with no indication of yes
or no in the headers or the message.) Simple email informing the voter that the
votes could not be counted were sent, and in each case a new valid vote
was sent by the voter.

Thanks to everyone who voted, and I look forward to some interesting
discussions in the future.

                    David B. Stewart
                    <[e-mail]>


No votes (19)
=============================================================
AH Al_ashaab <[e-mail]>
Charles Shub <[e-mail]>
Eric J. Olson <[e-mail]> [2 votes reduced to 1]
Gerry Roston <[e-mail]>
Jon Lin <[e-mail]>
Sven M. Heinicke <[e-mail]> [2 votes reduced to 1]
[e-mail]
[e-mail] (Austin G. Hastings)
[e-mail] (James Barrett)
[e-mail] (Joe Brandt))
[e-mail]
devon![e-mail]
[e-mail] (Paul Eggert)
[e-mail] (Ed McGuire)
[e-mail] (Gregory G. Woodbury)
kumr!abekas.UUCP![e-mail] (Mike Park)
pseudo![e-mail] (Murray Nesbitt) [2 votes reduced to 1]
[e-mail] (Richard H. Miller)
[e-mail] (Mikael Parknert)

Yes Votes (227)
==============================================================
88opensi![e-mail]
Anay S. Panvalkar <[e-mail]>
Andre Somberg <inducom![e-mail]>
Andy Jackson <[e-mail]>
Bob Foery <[e-mail]>
Bob Herlien <[e-mail]>
[e-mail]
Brian Carlton <[e-mail]>
Brian Palmer <[e-mail]>
Brian e. Batson <[e-mail]>
Christoph Eck <[e-mail]>
[e-mail]
DONALD MACKELLAR <[e-mail]>
David Lee <[e-mail]>
[e-mail]
Denis Poussart <[e-mail]>
Edgar Perez <[e-mail]>
Edward McClanahan <[e-mail]>
Einar Sjaavik <[e-mail]>
[e-mail]
[e-mail] (Florian Wohlgemuth)
Glenn Kasten <[e-mail]>
HOGLE RICHARD A <[e-mail]>
Henning Pangels <[e-mail]>
James McIntosh <[e-mail]>
James Olsen <[e-mail]>
Jan Ekkel <inducom![e-mail]>
Jian Huang <[e-mail]>
Jim Cockrell @ NSI <[e-mail]>
Joe Weintraub <[e-mail]>
John Heimbold <[e-mail]>
John Sauter <[e-mail]>
John M. Jourdain <[e-mail]>
Jon Kieffer <[e-mail]>
Jurriaan Vreeburg <[e-mail]>
Kai Atle Myrvang <[e-mail]>
Klaus Rennecke <[e-mail]>
[e-mail] (Larry Anglin)
Mark Williams <[e-mail]>
Mark Wuest <violin![e-mail]>
Markus Traber <[e-mail]>
Matthieu Herrb <[e-mail]>
Meindert Kuipers <inducom![e-mail]>
Michael M. O'Dorney <[e-mail]>
Michael Quinn <[e-mail]>
[e-mail]
Oded Ravid <[e-mail]> [2 'yes votes reduced to 1]
[e-mail] [2 'yes votes reduced to 1]
Paul Wilkinson <[e-mail]>
Paul Qualtrough <[e-mail]>
Pete Lyall <[e-mail]>
Phil Kester <[e-mail]>
Pirawat Watanapongse <[e-mail]> [2 'yes' votes reduced to 1]
Reidar Strand <[e-mail]>
Remko van Driel <inducom![e-mail]>
Rene Leiva <[e-mail]>
[e-mail]
Robert J. Docktor <[e-mail]>
Rolf Dietze <[e-mail]>
Ron Fox <[e-mail]>
[e-mail]
Sean Quinlan <[e-mail]>
Sinan Karasu <[e-mail]>
Steve Blachman <[e-mail]>
Steven King [phone] <[e-mail]>
Stuart Quick <[e-mail]>
Sundar Kuttalingam <wiltel![e-mail]>
Timothy J Chappell <[e-mail]>
Venneman John <[e-mail]>
Vincent Verleun <[e-mail]>
Vuorimaa Petri Kalevi <[e-mail]>
Walter E Miller @ NSI <[e-mail]>
[e-mail]
[e-mail] (Alex L. Bangs)
[e-mail] (Adams)
[e-mail]
[e-mail] (Tony Poyner) [2 'yes votes reduced to 1]
[e-mail] (barry n nelson)
[e-mail] (Bob Bieszk) [2 'yes votes reduced to 1]
[e-mail]
[e-mail] (Alan K Biocca)
[e-mail] (Bruce M. Walker)
[e-mail] (Dietmar Budelsky)
[e-mail] (Paul Butler)
[e-mail] (Carl Lowenstein)
[e-mail] (Alan Cheilek)
[e-mail] (Chris Tilt)
[e-mail] (Christian Lam)
[e-mail] (Gianni Comoretto)
comtec!tang![e-mail] (Robert Redfield)
[e-mail] (Craig Conway)
crispen <@ada3.ca.boeing.com:[e-mail]>
[e-mail] (Rodney Cummings)
[e-mail] (John Curry)
[e-mail] (Brian Curtiss)
[e-mail]
[e-mail] (Carl Kalbfleisch)
[e-mail] (Bill Sheppard)
[e-mail] (Daniel R. Kegel)
[e-mail] (Dave Peterson)
[e-mail] (Dawn Stewart)
[e-mail] (Dave Bruce)
dbsun![e-mail] (harbison)
[e-mail] (Darrell Call)
[e-mail] (Dan Ciarlette)
[e-mail] (David Kocinski)
[e-mail] (Donald R. Newcomb)
[e-mail]
[e-mail] (Peter Dufault)
[e-mail] (Don Wells)
ediger![e-mail] (Keith Neufeld)
[e-mail] (Erik Plesner)
[e-mail] (Albrecht Ernst)
[e-mail] (Ed Rolfe)
eurocor![e-mail] (Mike Geipel)
[e-mail] (Ed Faught)
[e-mail] (Floyd Miller)
[e-mail] (Jens Ebert (69-6305-299))
[e-mail] (Theresa Babrauckas)
[e-mail] (john galloway) [2 'yes votes reduced to 1]
[e-mail] (Ganesan)
gca![e-mail] (Peter Faill)
[e-mail]
[e-mail] (Gerd Buntkowsky)
[e-mail] (Steve Gilbert)
[e-mail] (Greogry J. Nawrocki)
[e-mail] (Glen Sescila)
[e-mail] (Gordon Miller)
[e-mail] (Gary Rima)
[e-mail] (Gillian Groves)
[e-mail] (Gerd Truschinski)
[e-mail] (Guy Cole)
[e-mail] (Harry Langenbacher)
[e-mail] (Ron Heiby)
[e-mail] (Heidi Frock)
[e-mail] (Jeff Hill)
[e-mail] (John Hodapp)
[e-mail]
[e-mail] (Mike Jablin)
[e-mail] (Jaime Edwards)
[e-mail] (John C. Peden)
[e-mail] (Joe Finnivan)
[e-mail] (Jim Horstkotte)
[e-mail] (John E. Kreznar)
[e-mail] (James D. Moudy)
[e-mail] (Joe Smith)
[e-mail] (Terry A. Jones)
[e-mail] (Jon Mott)
[e-mail] (John Tillema)
[e-mail]
[e-mail] (Kathryn Fielding)
[e-mail] (Douglas Kemp)
[e-mail] (Kevin Pammett)
[e-mail] (Graulle Christophe)
[e-mail]
[e-mail] (Steve Lewis)
[e-mail]
[e-mail] (mark milligan)
[e-mail] (Kenneth Mtz. (YONIX))
mcrware![e-mail] (John Lengeling)
[e-mail] (Mustafa Soysal)
[e-mail]
[e-mail] (Mohan J. Kumar)
[e-mail] (Maxime Taksar KC6ZPS)
[e-mail] (Mike Oliver)
[e-mail] ("Mr. Mike" Passaretti)
[e-mail] (Manish S. Vaidya)
[e-mail] (David Muir Sharnoff)
mwca![e-mail] (Bill Sheppard)
[e-mail] (Jeff Myer)
[e-mail]
[e-mail] (Norbert Nicolay)
[e-mail] (G. Pardo-Castellote) [2 'yes votes reduced to 1]
[e-mail] (Paul Antoine)
[e-mail] (Patrick D. Wolf)
[e-mail] (Scot McIntosh)
[e-mail]
[e-mail] (Robert Belshe)
[e-mail] (Raj Shelke)
[e-mail] (George Rice)
[e-mail] (Rick Spanbauer)
[e-mail] (Sylvain Riendeau 8573)
[e-mail] (Bob McKenzie)
[e-mail] (Robert Canik)
[e-mail] (Bob Robison)
[e-mail] (Glenn Robnett)
[e-mail] (Benno Lange)
[e-mail] (David Ross) [2 'yes votes reduced to 1]
[e-mail]
[e-mail] (ruman)
[e-mail] (Peter Salerno)
[e-mail]
[e-mail] (David Sawey)
[e-mail] (Seth A. Phillips)
[e-mail] (Tian Shen)
[e-mail]
[e-mail] (Don Slater)
[e-mail] (Steve M. Blumenau)
[e-mail] ( Steve Broadstone)
[e-mail] (Steve Morris)
[e-mail] (Steve Rogers)
[e-mail] (Flemming Stassen)
[e-mail] (Steve Zanoni 5-4325)
[e-mail] (Struck)
[e-mail] (Stu Labovitz)
[e-mail] (Tom Carey)
[e-mail] (Ted Eggers)
[e-mail] (Andy Thomson)
[e-mail] (Richard E. Neitzel)
[e-mail] (Tony Mountifield)
[e-mail] (Ted Shannon) [2 'yes votes reduced to 1]
tweekco![e-mail] (A.Lizard)
[e-mail] (Joe VanAndel)
[e-mail]
[e-mail] ( Volker A. Brandt )
ward horner <[e-mail]>
[e-mail] (Bill Brown) [2 'yes votes reduced to 1]
[e-mail]
[e-mail]
[e-mail] (Don Willey)
[e-mail] (John R. Winans)
[e-mail] (Isaac Wong)
[e-mail]
[e-mail] (Bill McDowell)
[e-mail] (Dave Wybo)
[e-mail] (yoshio nakamura)
[e-mail] (Yves Boudreault)

-----------------------------

From: Curtis Yarvin <[e-mail]>
Subject: Re: Does Linux use segmentation?
Date: 13 Nov 92 16:26:29 GMT
NNTP-Posting-Host: cobra.cs.berkeley.edu
To:       [e-mail]

In article <[e-mail]> [e-mail] writes:
>
>There are actually Multics systems still around, it's not the failed lab
>experiment that most text books would lead you to believe. Although
>Multics didn't meet all of it's initial design goals, it wasn't a failure.
>The main reason it didn't catch on was mostly due to a lack of marketing.

The reason it didn't catch on is because it was a _heinous beast_.

Followups to comp.unix.wizards, which has hashed out this thread more
than once before and will surely be glad to provide you with a
summary.

c

-----------------------------

From: P S Narayan <[e-mail]>
Subject: system call write
Date: 13 Nov 92 16:48:55 GMT
Sender: Read News <[e-mail]>
To:       [e-mail]

When I do a write (fd, buf, bytes), assuming that the file descriptor refers
to an open block device say disk, is the kernel going to copy buf from user
space to system buffer or is it going to flush it immediately onto disk ?
System V literature says that it is copied onto buffer and then by LRU
algorithm, it gets flushed when another process tries to access this buffer.
In that case how can the user process without closing the files, ensure that
his write system call flushes info onto disk ? Is there a way to do it ?

My question is how can I get synchronous write ?

Thanks
Narayan
[e-mail]

-----------------------------


End of UNIX-WIZARDS Digest
**************************