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

Internet Message Format | 1992-11-24 | 52.0 KB

Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!lhc!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 22:16:11 GMT
Sender: [e-mail]
Lines: 1370


 ----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 09:14:00 EST
From: [e-mail]
Subject: UNIX-WIZARDS Digest  V17#003
To: "DGRAY" <[e-mail]>

Return-Path: <[e-mail]>
Received: from SEM.BRL.MIL by milo.starlab.csc.com with SMTP ;
          Sun, 22 Nov 92 09:13:18 EST
Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa25954; 21 Nov 92 8:03 EST
Received: from sem.brl.mil by SEM.BRL.MIL id aa25810; 21 Nov 92 7:40 EST
Date:       Sat, 21 Nov 92 07:40:22 EST
From:       The Moderator (Mike Muuss) <[e-mail]>
To:         [e-mail]
Reply-To:   [e-mail]
Subject:    UNIX-WIZARDS Digest  V17#003
Message-ID:  <[e-mail]>

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

Today's Topics:
                       Re: The Problem with UNIX
                 Help!  Need to restore without backup
               Re: Help!  Need to restore without backup
                       /bin/ps (SysVr2 -> SysVr3)
                              asm. in UNIX
       Re: >>TAR file on tape distroyed, are files recoverable?<<
                          fflush() on a socket
                        Re: fflush() on a socket
Intro to comp.unix.wizards - read before posting! (weekly announcement, last change: Oct 29 00:48)
                                amnesiac
                              Re: amnesiac
                         Re: system call write
                                Thanks,

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

From: Ben Ketteridge <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 09:43:36 GMT
Sender: Benjamin Thomas Ketteridge <[e-mail]>
Nntp-Posting-Host: aberda
To:       [e-mail]

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?
For example, just to take the 'cat a b > b' problem, you are suggesting IMHO that
the shell shouldn't check redirection of output against the input and warn the
user in this case.

ciao
+--------------------------------------------------------------------------+
|    _|--|_    | Disclaimer: I know nothing! Do you really know anything?  |
|     (\/)     +-------------------------------+---------------------------+
|      vv      | We've a Gremlin in the works! |      [e-mail]       |
+--------------+-------------------------------+---------------------------+

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

From: "david.e.wexelblat" <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 17:48:47 GMT
To:       [e-mail]

In article <[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"
> >
> >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

Get real.  In your example, replace /bin/cat with /bin/echo:

    /bin/echo a b > b

What should "unix" do here?  You are confusing the OS, the shell, and
the program.  The various responsibilities are distributed.  Cripe -
MS-DOG has redirection, and will do the same screwup for commands that
are not built into COMMAND.COM.  I doubt that JCL protects you either.

Or would you rather have no I/O redirection, and force all the programs
to do all the I/O themselves?  How would you handle pipelines?

As soon as you try to protect users from themselves, you destroy
the usefulness of the system.  Who ever said that Unix is supposed to
be the "One True OS" (other than USL :->)?  Don't destroy the usefulness
of my OS because people who shouldn't be using it are involved.

--
David Wexelblat <[e-mail]>  [phone]
AT&T Bell Laboratories, 200 Laurel Ave - 4B-421, Middletown, NJ  07748

"The meaning of life?  That's simple.  Try to be happy, try not to hurt
 other people, and hope to fall in love."  -- Mallory Keaton

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

From: Donn Cave <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 18:01:32 GMT
Sender: USENET News System <[e-mail]>
To:       [e-mail]

[e-mail] (Mark Evans) writes:

|[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. ...

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

VMS does in fact have a command interpreter, DCL.  From a programmer's point
of view, it's a callable system interface that yields up the parsed command
line.  From the user's point of view, it's a fairly regular command language
with consistent rules about abbreviations and optional parameters.
Unfortunately, it's pretty weak as a programming language, but it does have
"lexical functions" built in to do things like parse file names and wildcards,
get system information of various kinds and do some text manipulation.

I'm not strong on VMS internals, but I don't think the command line goes
into a PCB, but rather is stored in a DCL supervisor area per user - VMS
may be a little more complex than UNIX in this respect.  There's a command
history, which presumably is also stored there.  Changing the command set
does not require rebuilding the system, and users may adopt their own
command tables or add their own customizations.  Updating the command table
can be problem, since the change doesn't affect current jobs, but that's
an implementation issue.

Probably the biggest issue for the programmer is that DCL doesn't expand
wild cards.  VMS applications expand wild cards using file system services,
which is much harder programming work but gives you a lot more control over
the semantics of the operation, as opposed to (int argc, const char **argv).
For example, one may use the file specification in one parameter to supply
defaults for the specification in another parameter, further controlling
whether the defaults are to be applied using output (new) file or input
(old) file semantics.  That makes "RENAME *.C .C-DIST" a natural idiom in
VMS, where in UNIX the same operation ("how do I rename a group of files")
regularly generates questions on this news group.  It does however mean
that applications accept wild cards only if the programmer invested the
time.

    Donn Cave, University Computing Services, University of Washington
    [e-mail]

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

From: Boyd Roberts <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 18:08:04 GMT
Sender: USENET News System <[e-mail]>
Nntp-Posting-Host: prl313.prl.dec.com
To:       [e-mail]

In article <[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
>

It has nothing to do with the shell;  read the message.

cat has done that for a long time.


Boyd Roberts            [e-mail]

``Not only is UNIX dead, it's starting to smell really bad.''  -- Rob Pike

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

From: Eric Eide <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 19:32:14 GMT
To:       [e-mail]

I wrote:

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

And Jurgen Botz ([e-mail]) wrote:

Jurgen> Without wanting to make a judgement about the viability of the basic
Jurgen> research underlying such a project, why are you starting with the C
Jurgen> shell?  If I wanted to create a user-interface that could deal with
Jurgen> errors and ambiguities introduced by the user I would first make sure
Jurgen> that the software itself isn't full of errors and ambiguities... i.e.,
Jurgen> I sure as hell wouldn't use the C shell.

Good point.  The reason that I chose the C shell is that within the Univeristy
of Utah's Department of CS, it is the most commonly interactively-used program
with a command-line interface.  This makes it easy to find lab rats... er,
guinea pigs... um, volunteers to test my improved interface.  And since the C
shell is so commonly used, it seemed that improvements to the C shell would be
most valuable.  That is, a "smart shell" would be more valuable than a "smart
ftp."

In many ways the C shell is a bad candidate for smarts.  Most of the shell's
"command set" is implemented by programs that have no real connection to the
shell.  This "command set" is inconsistent (e.g., different programs accept
different argument syntax).  And the shell itself has bugs and ambiguities.
But on the other hand, of all the programs available in UNIX, the C shell is
arguably the program in which intelligence would be most useful.

So I made my choice based on the potential value of the improvements.

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

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

From: Anthony P Lawrence <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 19:43:34 GMT
X-Newsreader: Tin 1.1 PL3
To:       [e-mail]

[e-mail] (der Mouse) writes:
: 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.

True, but: shouldn't we have an interest in keeping Unix alive in
the general use arena?  If SuperDos VIII completely takes over,
aren't we left in the same position as those wonderfully strange
folks who still run CP/M ?

Personally, I don't want a shell that thinks very much about what
I might have meant.  But I think it would be real nice if there
were such a sissified but friendly little helper around that I
could use for the people who hate anything I can give them now.

        Tony   [e-mail]

Lawrence & Clark, Inc        [phone]    [phone]
Xenix/Unix support,etc           Boston         Seattle

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

From: Michael Lemke <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 21:31:07 GMT
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?
>For example, just to take the 'cat a b > b' problem, you are suggesting IMHO
>that
>the shell shouldn't check redirection of output against the input and warn the
>user in this case.

Actually, I think this example should work!  It is a perfectly
reasonable request.

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

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

From: Michael Lemke <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 22:32:42 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Donn Cave) writes:
>[e-mail] (Mark Evans) writes:
>
>|[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. ...
>
>| 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)
>
>VMS does in fact have a command interpreter, DCL.

When I wrote my little remark up there I actually had VMS in mind.
Several people pointed out in the meantime that there is getopt (3), of
which I wasn't aware at the time of writing.  Well, that is a least a
start but as some people also remarked it is somewhat limited and
overkill in other cases.  Does it allow optional parameters (I know
getopts in the Bourne shell does not)?

>From a programmer's point
>of view, it's a callable system interface that yields up the parsed command
>line.  From the user's point of view, it's a fairly regular command language
>with consistent rules about abbreviations and optional parameters.
>Unfortunately, it's pretty weak as a programming language,

True, but we weren't talking about programming although that is a very
important aspect too.

>but it does have
>"lexical functions" built in to do things like parse file names and wildcards,
>get system information of various kinds and do some text manipulation.

Although definately not as flexible as Unix it is consistent on every level,
i.e., if you parse a filename with f$parse/f$scan from DCL or call
lib$find_file from a program the behavior is identical.  And concerning
command line parsing the CLI$ routines are easily callable from any
language and can even be used for the internal command driven interface
of your application program.  Their use is a little complex but command
line parsing is a complex problem -- lex isn't easy to use either (I
can't).

>
>I'm not strong on VMS internals, but I don't think the command line goes
>into a PCB, but rather is stored in a DCL supervisor area per user - VMS
>may be a little more complex than UNIX in this respect.  There's a command
>history, which presumably is also stored there.  Changing the command set
>does not require rebuilding the system, and users may adopt their own
>command tables or add their own customizations.  Updating the command table
>can be problem, since the change doesn't affect current jobs, but that's
>an implementation issue.
>
>Probably the biggest issue for the programmer is that DCL doesn't expand
>wild cards.  VMS applications expand wild cards using file system services,
>which is much harder programming work but gives you a lot more control over
>the semantics of the operation, as opposed to (int argc, const char **argv).

Well, it is really not that hard to do.  Just call lib$find_file in a
loop until it returns RMS$_NMF.  You'll need the loop anyway.

>For example, one may use the file specification in one parameter to supply
>defaults for the specification in another parameter, further controlling
>whether the defaults are to be applied using output (new) file or input
>(old) file semantics.  That makes "RENAME *.C .C-DIST" a natural idiom in
>VMS, where in UNIX the same operation ("how do I rename a group of files")
>regularly generates questions on this news group.  It does however mean
>that applications accept wild cards only if the programmer invested the
>time.

That is certainly true.  But I am very much convinced that none of the
typical Unix users understand that the shell is expanding the wildcards
and they will be rather very surprised to see echo * produce a strange
ls listing.  On the other hand not many people completely understand the
sticky defaults you just described either.

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

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

From: Michael Lemke <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 22:47:18 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] writes:
>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
>

No, I don't.  I am complaining that the options are a) parsed
inconsistently (`bla -lx a' might be valid and `bla -l x a' not but
`foo -l x a ' is ok and `foo -lx a' is not) and b) that -l means long
for ls -l but library for f77 -l.  I want ls -long and f77 -library and
be able to abbreviate both -long and -library because `long' and
`library' is what I mean and not -l.

I am not addressing the question of parameter substitution and I/O
redirection at all as you do in the rest of your post.  That would open
a whole new can of worms.

[worms eaten by the fish]

>
>
>It sounds like most of your problem is due to the large number of UNIX
>utilities. How many does DOS have?

No idea.  I don't know DOS.

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

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

From: Robert Hartman <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 23:29:27 GMT
Sender: Usenet News <[e-mail]>
To:       [e-mail]

In article <[e-mail]> [e-mail] (Mark Evans) writes:
>[e-mail] (Michael Lemke) writes:
 ...
>: > ... 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.

[discussion of no standard options problem omitted for brevity]

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

You know, I see merit in both of these approaches.  The command line
parser should be a library routine in stdio.  The shell should use
command and option completion prior to exec, and the command history to
autocorrect typos when the parsing routine returns an error.  This
routine could perhaps be called by the shell as the last step prior to
calling exec to save system overhead of having to create a process
only to return an immediate error.

-r

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

From: "Paul O. Hart" <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 02:00:19 GMT
Sender: [e-mail]
To:       [e-mail]

Quoted from [e-mail] (Anthony P Lawrence) in <[e-mail]>:
->Personally, I don't want a shell that thinks very much about what
->I might have meant.
->
->        Tony   [e-mail]
->
->Lawrence & Clark, Inc        [phone]    [phone]
->Xenix/Unix support,etc           Boston         Seattle

This IS the point.  UNIX has always been a collection of tools
which the user can put together in any way he/she deems fit.  If
the user would RTFM there would be no problem and they would get
what they want.  Don't like the way a shell does something ?  Do
something about it by writing a program or making a script.  Stop
whining !




--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Eternal  nothingness is fine, ||**|| Paul O. Hart,   12m Operations Group |
| if  you happen to  be dressed ||**|| National Radio Astronomy Observatory |
| for it.           Woody Allen ||**|| Tucson, Arizona   {>  {>  {>  {>  {> |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=^=-=^=-=^=-=^=-=^=-=

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

From: Peter Busser <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 14:59:43 GMT
To:       [e-mail]

[e-mail] (Karl Anderson) writes:

>Is there any reason why there can't be another stream for more
>user-friendly messages?

Yes! Feeping creaturism. I'm pro user friendly messages, but, IMHO, consistency
and clarity are much more important than verboseness. Furthermore, it would
require existing programs to be extended with the verbose message.

A better approach would be, IMHO, to leave the messages what they are and make
every program return a meaningful error number. A seperate program could
figure out which verbose message belongs to that number. That saves several K's
of text for each program and makes translation to foreign langauges much
easier. The user who uses such a tool gradually learns to associate the terse
error message to the verbose description. After a while, (s)he wouldn't need
the verbosity tool much anymore. That way the learning curve is less steep and
it doesn't affect the guru type, who ignores that verbosity tool, at all.

The attitude that it needs a steep learning curve to be useful is nonsense.

BTW, the above mentioned 'verbosity tool' is actually used by OS/2. Although
the difference is that OS/2 prints an error number and you have to type the
error number on the command line to get a meaningful message.

BTW^2, OS-9 (which has nothing to do with Plan 9 or OS/2) has a shell built-in
command which sets the verbosity level (the shell takes care of printing the
error messages, as far as I can remember, the command just returns the error
number) to either 'short' or 'long'.

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

From: Peter Busser <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 15:13:18 GMT
To:       [e-mail]

[e-mail] (Antony A. Courtney) writes:

>>So, Boyd, if UNIX really is dead, where is the funeral? I would so enjoy
>>paying my last respects ...

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

That's a good point! For instance, instead of using the creat() system call,
which creates a file with given permissions, they added a parameter open() to
duplicate the functionality of creat().

>UNIX is dead.  Long live UNIX.

Long live Plan 9?

Greetings,
Peter Busser

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

From: Peter Busser <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 15:20:13 GMT
To:       [e-mail]

[e-mail] (Arne Henrik Juul) writes:

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

That's nonsense, even DOS can do that:

  COPY /B FILE.1+FILE.2+FILE.3 FILE.ALL

It's ugly, but it works anyway.

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

From: Peter Busser <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 15:22:35 GMT
To:       [e-mail]

[e-mail] (Bill Vermillion) writes:

>cat a b > b    I get this result

>cat: input/output files 'b' identical

GNU bash says:
cat: b: input file is output file

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

From: Peter Busser <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 15:38:57 GMT
To:       [e-mail]

[e-mail] (der Mouse) writes:

>    cat a b > b

>files?  Consider instead "echo a b > b".[%]

I did just that with bash and it didn't complain. But yet, echo is often a
built-in command. It complained about 'cat a b >b' but didn't complain about
'cat a b|cat>b' so it's not perfect.

>switched to using dd, which mercifully had not been broken by some
>overzealous fool trying to keep people from shooting themselves in the
>foot.

<GRIN>

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

Acceptance in the general microcomputer market also means more software, lower
prices, more support (every (S)VGA card ships with Windows drivers, but X11
support is harder to get), more UNIX related jobs (or do you prefer to use
Windows at work? :), more UNIX everything.

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

From: Leslie Mikesell <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 17:59:45 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] writes:

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

I meant the transport does the right thing in delivering the message as
sent.  I didn't think anyone actually used SysV mail's user interface
(or lack thereof).

>This user says `Plugh!'

Do yourself a favor and compile ELM.

>(Really, until we all use some form of BLOB-linked-in-text we'll have this
>argument over and over.)

MIME attachments address this and it's likely to catch on fast.  However
while it's nice for the user interface to understand content types it's
not really any more necessary than for cp/cpio/tar to understand what
they are copying.

Les Mikesell
  [e-mail]

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

From: Boyd Roberts <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 21:12:14 GMT
Sender: USENET News System <[e-mail]>
Nntp-Posting-Host: prl313.prl.dec.com
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Donn Cave) writes:
>
> VMS does in fact have a command interpreter, DCL.  From a programmer's point
> of view, it's a callable system interface that yields up the parsed command
> line.  From the user's point of view, it's a fairly regular command language
> with consistent rules about abbreviations and optional parameters.

Yeah what I love about VMS is that it's regular:

    $ show queue eve
    ...
    $ start queue eve
    %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
 \EVE\
    $ start/queue eve
    %JBC-E-STARTED, queue already started


Boyd Roberts            [e-mail]

``Not only is UNIX dead, it's starting to smell really bad.''  -- Rob Pike

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

From: Steve Bacher <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 21:24:00 GMT
Sender: MVS NNTP News Reader <[e-mail]>
Nntp-Posting-Host: mvs.draper.com
To:       [e-mail]

In article <[e-mail]>,
[e-mail] (Donn Cave) writes:

>[e-mail] (Mark Evans) writes:
>
>|[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. ...
>
>| 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)

[discussions of getopt(3) and VMS DCL deleted...]

MVS TSO (don't barf) has this feature.  TSO commands call a PARSE
service routine that you give a definition of all the command operands,
what sorts of syntactical entities they take (covering a lot of common
formats), where to stick the results, etc.  The operands can be
abbreviated in predictable and standard ways.  Users are automatically
prompted for missing or invalid operands.  The program sees only the
final correct inputs after prompting is completed.

The specifications are internal to the program; they do not have to
be defined in some external location by some systems programmer.
And a command processor is free to not call parse at all but just
look at the raw command line if it wants to.

Wildcarding is not done by the parse service, but by a catalog lookup
routine callable by the command processor which returns a list of
filenames that match the pattern.  Admittedly, the patterns under
TSO are ridiculously limited and the programming is complicated,
but the theory is sound.

Oh, but of course IBM couldn't possibly have done anything right...

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: [e-mail]                Cambridge, MA, USA

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

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

In article <[e-mail]> [e-mail] (Paul O. Hart) writes:

>This IS the point.  UNIX has always been a collection of tools
>which the user can put together in any way he/she deems fit.

Yes, and UNIX has always come with an administrator to do it for
you - sometimes even with people with access to the source so they
could really make the changes you want.  Those days are over for
most folks.  Today you are expected to solve your own problems and
people are used to out-of-the box solutions.

>If the user would RTFM there would be no problem and they would get
>what they want.  Don't like the way a shell does something ?  Do
>something about it by writing a program or making a script.  Stop
>whining !

But it's a mass-market world out there. Why should everyone have to
solve the same programming problems?  You are right that it isn't
a UNIX problem - it's just a lack of a generally accepted friendly
shell.  Just try to apply your arguments to the business world (or
anywhere else where you have to get some real work done instead of
spending your life with the FM).  Would you run a business with the
secretaries saving files by typing > at the shell?  How often do
you think they'll hit arrow keys and get an escape sequence imbedded
in a filename?  How much will it cost you to train them to the point
where they get it right 99% of the time?  How long will it be before
someone types "rm -rf directory *" instead of "rm -rf directory &"?
(That one actually happened when someone who should have known better
was helping me out, but it's just one key away).   These problems
could be solved as easily under unix as anywhere else, except for
the fact that people who have spent years learning unix have forgotten
that there is a problem.

Les Mikesell
  [e-mail]

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

From: Marc Unangst <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 15 Nov 92 10:38:49 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Bryan S. So) writes:
>1. We should assume some stubborn users cannot be educated.  I
>   claim without proof such users exist.

I will agree with your claim that such users exist; however, a better
question to ask is whether we should bother with stubborn people who
refuse to be educated in the first place.  Unless they are your boss,
there really is no reason to force someone to use an OS that they
obviously don't want to use in the first place; give them their
Macintosh and their user-cuddly interface and let them be happy.  Of
course, they might not get as much done, but that's their problem.

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

Assuming, of course, that "prepend a to b" is what the user meant.
It's possible that they meant "concatenate a and b and send the output
to v", and that they simply made a typo.  In which case prepending a
to b would most definitely *not* be what the user wanted, and generate
a lot of extra work for them to boot (specifically, removing a from
the top of b by hand).

>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".

Uh, right.  How does "Unix" know that b is both input and output?  The
shell doesn't know; all that's happened is that it has been asked to
run a program, "cat", and pass it the two arguments "a" and "b", and
send the output to a file called "b".  The "b" on the command line may
or may not refer to the file called "b", and cat may or may not decide
to read from it.  By the time cat has started up and made things
obvious to the kernel that "a" and "b" are input files, "b" is gone,
because the shell truncated it before it exec'd cat.

There are also problems with buffering the input.  What if the "b" is
a FIFO or a device, not a regular file?  In that case, "cat b > b" is
perfectly valid and not at all abnormal.  What if "b" is a Unix-domain
socket, and the program at the other end writes something and then
waits for a response before closing the file?  Your program will never
run, because Unix will be sitting there waiting to read the "rest" of
the input file before giving the program control.

Perhaps what we *really* need is a -o flag for cat, similar to the one
on sort.

--
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: Rich Kulawiec <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 15 Nov 92 16:43:20 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] (Leslie Mikesell) writes:
>These problems could be solved as easily under unix as anywhere else,
>except for the fact that people who have spent years learning unix
>have forgotten that there is a problem.

"Problem" is a matter of opinion; I consider the items you list "features",
and find the occasional toasting that they give to a user who didn't RTFM
a helpful educational tool.  I happen to like the expert-friendly
and relatively unforgiving nature of most Unix implmentations.  Those
who feel otherwise are certainly free to implement whatever warm-fuzzy-
hand-holding-protect-the-user-from-themselves features they wish.

---Rsk

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

From: Marc Unangst <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 15 Nov 92 20:26:23 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (Peter Busser) writes:
>I did just that with bash and it didn't complain. But yet, echo is often a
>built-in command. It complained about 'cat a b >b' but didn't complain about
>'cat a b|cat>b' so it's not perfect.

You fail to see the point.  It's useless for cat to complain, because
once cat gets to run "b" has already been clobbered by the shell.  Try

$ echo foo >foo
$ echo bar >bar
$ cat foo
foo
$ cat bar
bar
$ cat foo bar >bar
cat: input/output files 'bar' identical
$ cat bar
foo
$

--
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: Chris Maltby <[e-mail]>
Subject: Re: The Problem with UNIX
Date: 16 Nov 92 06:21:56 GMT
Sender: Usenet <[e-mail]>
To:       [e-mail]

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

>Things that bother me about the command line (I'm using Motorola
>UNIX System V/68 Release 3.71 running a Korn shell using vi-type
>command line editing on a VT420), in no particular order:
>
[6 (what, only 6!) shortcomings of ksh-vi deleted]
>
>That's a short list off the top off my head. If anyone has methods
>to fix these complaints please feel free to respond!

I'd suggest that you do as was suggested by someone else in this thread.
First read "cat -v considered harmful" and then consider whether your shell
should contain a text editor, or whether your shell should co-operate with
your text editor to solve your problem.

ksh, bash, zsh whatever - it's part of why Rob Pike and Boyd Roberts are
making that sort of remark about UNIX. Underneath all that sludge is quite
a nice operating system...

For your information, you'll find that rc (and my shell too :-) copy what
you type into a history file. If you want to edit bits of that with sam,
vi or even EMACS, it just works. Simple, isn't it.
--
Chris Maltby - Softway Pty Ltd        Internet: [e-mail]

PHONE:    [phone]    "I'm waiting for X-Windows to become just that;
FAX:    [phone]     Ex-Windows" - A McGrath.

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

From: Alice Booth CT/90 <[e-mail]>
Subject: Help!  Need to restore without backup
Date: 13 Nov 92 19:33:58 GMT
Sender: [e-mail]
Followup-To: comp.sys.hp
Nntp-Posting-Host: rcsuna.gmr.com
To:       [e-mail]


Turns out the user's data was being stored beneath this subdirectory, and we do
not have a backup.

I've shutdown the machine and am looking for a person or a service organization    to help me restore the data if possible.  I understand that it may be possible to
recreate the inode table and thereby retrieve the user's data files.

Any help will be greatly appreciated!  This occurred on an HP9000/750 at
HP-UX 8.07.

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

From: Alice Booth CT/90 <[e-mail]>
Subject: Re: Help!  Need to restore without backup
Date: 13 Nov 92 19:40:36 GMT
Sender: [e-mail]
Followup-To: comp.sys.hp
Nntp-Posting-Host: rcsuna.gmr.com
To:       [e-mail]

Please mail any helpful responses to
  [e-mail]

Thanks.

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

From: Forrest Aldrich <[e-mail]>
Subject: /bin/ps (SysVr2 -> SysVr3)
Date: 13 Nov 92 20:36:33 GMT
To:       [e-mail]

I'm interested in creating a program that will report information similarly
to that of SysVr3 /bin/ps.  IE:  the full command line and command arguments,
in particular.  SysVr2 /bin/ps does not provide this functionality...

I've been told that this might be complicated because it requires that you
have to look out on the swap device for this info, and this can be very
platform specific.

Since this is SysVr2, and is older, I wonder if anyone might have some
sample code that I might be able to go by, or perhaps know of something
out there I could use to do this...  any help would be appreciated.
Thank you.


--
       -----------          Forrest Aldrich          -----------
       -------     morwyn![e-mail]      -------
       ----                             ----
       --         VISION GRAPHICS --    Dover, NH - USA           --
       ------------------------------------------------------

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

From: Ji-Tzay Yang <[e-mail]>
Subject: asm. in UNIX
Date: 14 Nov 92 14:28:47 GMT
Sender: [e-mail]
X-Newsreader: TIN [version 1.1 PL6]
To:       [e-mail]


 Hello,

    The following is a very 'hard' question for me, because I can't find the
    information I need :-/

    if I want to write a piece of asm. codes in C on 386BSD.
    I can write :

       asm ("movl %ebx, %ebx");

    but what should I write if I want to move the address of varible 'foo'
    the '%eax'?

    void f() {
        int x, y;

        /* if we want
           %eax = &x
           %ebx = y
        */
        asm("movl ___, %eax);
        asm("movl ___, %ebx);
    }

    By the way, are there any books or documnets discussing
    the "inline asm" for UNIX?

    Hope there are kind people help me.
--
                                         With regard,

 ============================================================================
 Ji-Tzay Yang (7( 0r 8|)              |  E-mail : [e-mail]
 Dept. of Comp. Science & Info. Eng.  |           [e-mail]
 National Chiao-Tung University       |  Tel    : [phone] ext 6430
 Hsin-Chu, Taiwan ROC                 |  Fax    : [phone]
 ============================================================================

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

From: Norm MacNeil <[e-mail]>
Subject: Re: >>TAR file on tape distroyed, are files recoverable?<<
Date: 14 Nov 92 21:44:13 GMT
Sender: Use Net <[e-mail]>
Nntp-Posting-Host: bcarh1ff
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,

  I don't know if it'll work but try using dd.  For example,
    dd if=/dev/nrst0 of=/dev/null
  will read from the /dev/rst0 (non-rewinding) tape device and send the output
  to nothing.  This will get the tape point past the small file.  You should
  be able to type
    dd if=/dev/rst0 of=tar.file
  which will read the rest of the data off the tape and place it into tar.file.
  Now the problem is now to rectify the file so that tar can recogznie the
  format...

  This might be a start anyway.

    Norm.
+-----------------------------------------------------------------------+
 Norm MacNeil                     Phone: [phone]
 Data Systems                     Fax:   [phone]
 Bell-Northern Research Ltd.      EMail: [e-mail] (INTERNET)
 #include <disclaimer.std>       "Roller bladers do it in-line!"

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

From: Phil Romig <[e-mail]>
Subject: fflush() on a socket
Keywords: flush,socket
Date: 14 Nov 92 23:40:51 GMT
NNTP-Posting-Host: cse.unl.edu
To:       [e-mail]

Hello;

I need to know how to flush a socket.  I'm working on a distributed
application, with my sockets set for FNDELAY and FIOASYNC I/O.

The best solution would be to use fflush, but I have two problems.
Under SUN 0/S fflush(NULL) causes a segmentation fault (so I can't do
that) and I can't figure out how to find the pointer to the stream
for a particular socket (all I have is the file descriptor).

The problem is complicated by the fact that I'm working on both
SUN O/S and and ULTRIX.  ULTRIX does not support much of the newer
"streamio" stuff.

Anyone have any ideas?

Thanks for your help

-PHIL-
[e-mail]
Department of Computer Science
University of Nebraska, Lincoln

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

From: Kenneth Herron <[e-mail]>
Subject: Re: fflush() on a socket
Keywords: flush,socket
Date: 15 Nov 92 03:12:49 GMT
To:       [e-mail]

[e-mail] (Phil Romig) writes:

>The best solution would be to use fflush, but I have two problems.
>Under SUN 0/S fflush(NULL) causes a segmentation fault (so I can't do
>that) and I can't figure out how to find the pointer to the stream
>for a particular socket (all I have is the file descriptor).

Well, I can't really tell you what the right course of action is, but
fflush() is a red herring.  If you had been using the stdio library
with this socket, fflush() would flush the stdio buffers.  You're not,
so there are no stdio buffers, only kernel-level buffers (or whatever
sockets use).
--
Kenneth Herron                                              [e-mail]
University of Kentucky                                         [phone]
Dept. of Mathematics     "Your ball goes over them, it sails off the edge into
a huge cauldren of fire-breathing dragons."  "And they call this a par three?"

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

From: Brian Fitzgerald <[e-mail]>
Subject: Intro to comp.unix.wizards - read before posting! (weekly announcement, last change: Oct 29 00:48)
Date: 15 Nov 92 11:00:55 GMT
Expires: Tue, 15 Dec 1992 11:00:29 GMT
Followup-To: poster
Nntp-Posting-Host: mml0.meche.rpi.edu
To:       [e-mail]

Please take a moment to read this before posting to comp.unix.wizards
for the first time.

comp.unix.wizards is for in-depth discussion of advanced unix topics.

Elementary questions do not belong in comp.unix.wizards.  Although some
socket questions (for example) are appropriate, "How do I program with
sockets?" is not.

Crossposting to comp.unix.wizards and comp.unix.questions is
inappropriate.  Plenty of wizards read comp.unix.questions and answer
questions there.

A wizard is someone who can rewrite the entire system from scratch.  If
you are not a wizard, you are welcome to follow along the discussions
anyway.  You'll learn quite a bit about how UNIX works.  Caution: post
to wizards only if you are yourself a wizard.

For a list of answers to frequently asked questions (FAQ), please refer
to comp.unix.questions (or comp.lang.c, news.answers, etc...).  "How do
I delete a file whose name starts with a '-' ?" is an example of such a
question.  Please do not ask or answer FAQ's on the net.

Write to [e-mail] (Subject: subscribe.  Any
message.) if you want a daily digest of this newsgroup mailed to you.

To unsubscribe from the unix-wizards mailing list, send mail to
"[e-mail]", no text required.  It is incorrect to post
such requests to the list, or to mail them to me, though others may
mistakenly do so.

E-mail comments about this posting are welcome.  From time to time I'll
summarize them.

Brian
--
These opinions are mine, and do not necessarily reflect those of any
academic department or computing service at Rensselaer.

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

From: Jeff Wandling <[e-mail]>
Subject: amnesiac
Date: 15 Nov 92 11:10:15 GMT
To:       [e-mail]


sunos% strings /usr/etc/getty | grep Amnesiac
Amnesiac

It may seem like a really trivial questiion, but I just wanted to know
why the string "Amnesiac" is in getty.  Could someone mail me the source?

--
---
Jeff Wandling   <[e-mail]>  "will hack for food"

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

From: Wolfgang Prediger <[e-mail]>
Subject: Re: amnesiac
Date: 16 Nov 92 07:49:03 GMT
Sender: [e-mail]
X-Newsreader: TIN [version 1.1 PL6]
To:       [e-mail]

Jeff Wandling ([e-mail]) wrote:
>
> sunos% strings /usr/etc/getty | grep Amnesiac
> Amnesiac
>
> It may seem like a really trivial questiion, but I just wanted to know
> why the string "Amnesiac" is in getty.  Could someone mail me the source?
>
Amnesiac is shown in getty's login prompt if no hostname is set for
the machine.

That's all.

Wolfgang

--
Name : Wolfgang Prediger
Email: [e-mail]
Snail: Siemens AG, AUT 482, Gleiwitzer Str. 555, 8500 Nuernberg Germany
Voice: [phone] (work)
 --- "Beam me up, Scotty, there's no intelligent life down here !" ---

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

From: der Mouse <[e-mail]>
Subject: Re: system call write
Date: 15 Nov 92 20:39:22 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (P S Narayan) writes:

> 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 ?

This is of course system-dependent.  Every system I know of (which for
knowledge at this level is restricted to BSD derivatives) will have
copied the data out of your buffer by the time write() returns.  The
relevant buffers in the buffer cache will be marked dirty and will be
flushed to disk at the next sync() or when buffers are needed for some
other use.

> 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 ?

If you're accessing a file, I know of no way; at best you can make it
push the dirty pages immediately, but I don't know of any way to wait
until the I/O actually completes.  If you're using a special device, it
is of course up to the driver; all block special devices I know of
behave like files in this respect.  Character special devices are,
usually, better: they tend to wait until the I/O completes.

Of course, given things like caching disk controllers, it may not be
possible to tell whether the bits have actually reached the medium.

                    der Mouse

                [e-mail]

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

From: Domenico De Vitto <[e-mail]>
Subject: Thanks,
Date: 16 Nov 92 08:57:27 GMT
To:       [e-mail]

Thanks to all who explained to me what RTFRFC means,
most were highly abusive and couldn,t F*CKING well see that I'm not 'on' the
internet, from my address, and I only have news access across JANet, but
if anyone wants a list of unix biggots, mail me.

'wizzard' is a _relative_ term, and most at my uni (BSc comp sci) agree, I
need not prove it to you lot!

I did think that this group (that I've been reading for 2 years) had settled
down and didn't have any 'children' actively reading it, I was wrong (sadly).

Dom De Vitto

Dom De Vitto

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


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