HDTenEightyP/NetNews huggingface dataset:
From: barnett@grymoire.crd.ge.com (Bruce Barnett)
Newsgroups: comp.unix.wizards
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 15:30:27 GMT
	<BARNETT.92Nov12092045@grymoire.crd.ge.com>
	<1992Nov12.231845.14014@cs.wisc.edu>
Reply-To: barnett@crdgw1.ge.com
Organization: GE Corp. R & D, Schenectady, NY

In article <1992Nov12.231845.14014@cs.wisc.edu> so@brownie.cs.wisc.edu (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 <barnett@crd.ge.com> uunet!crdgw1!barnett
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: evansmp@uhura.aston.ac.uk (Mark Evans)
Subject: Re: The Problem with UNIX
Organization: Aston University
Date: Fri, 13 Nov 1992 10:47:31 GMT

michael@chpc.utexas.edu (Michael Lemke) writes:
: In article <EEIDE.92Nov12120339@asylum.cs.utah.edu> eeide%asylum.cs.utah.edu@cs.utah.edu (Eric Eide) writes:
: >Scott Beckstead (scott@yarc.uucp) 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                                   |evansmp@uhura.aston.ac.uk
+(44) 21 565 1979 (Home)                     |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |
Newsgroups: comp.unix.wizards,comp.unix.shell
From: apl@world.std.com (Anthony P Lawrence)
Subject: Re: The Problem with UNIX
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Tin 1.1 PL3
Date: Fri, 13 Nov 1992 19:43:34 GMT

mouse@thunder.mcrcim.mcgill.edu (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   apl@world.std.com

Lawrence & Clark, Inc		(617) 762-0707	(206) 323-2864
Xenix/Unix support,etc 	 	 Boston		 Seattle
From: postmaster@tintin.csl.sni.be
Newsgroups: comp.unix.wizards
Subject: smtp mail failed
Date: 12 Nov 92 22:39:06 GMT

Your mail to magellan is undeliverable.
---------- diagnosis ----------
---------- unsent mail ----------
From UNIX-WIZARDS Mon Sep  7 15:15:13 EST 1992 remote from BRL.MIL remote from tintin
Received: from BRL.MIL by tintin.csl.sni.be; Thu, 12 Nov 1992 23:25 MET
Received: by snibru.uucp (/\==/\ Smail3.1.25.1 #25.4)
	id <m0mplv4-00013HC@snibru.uucp>; Thu, 12 Nov 92 22:17 MEZ
Received: from vm1.NoDak.edu by ub4b.buug.be (5.65c/ub4b_02)
	id AA25771; Thu, 12 Nov 1992 23:07:50 +0100
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP V2R2)
   with BSMTP id 5674; Thu, 12 Nov 92 16:06:40 CST
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 2658; Thu, 12 Nov 92 16:06:37 CST
Message-Id: <199211122207.AA25771@ub4b.buug.be>
Date:         Mon, 7 Sep 1992 15:15:13 EST
Reply-To: UNIX-WIZARDS@BRL.MIL
From: "The Moderator (Mike Muuss)" <Unix-Wizards-Request@BRL.MIL>
Subject:      UNIX-WIZARDS Digest  V16#002
X-To:         UNIX-WIZARDS@BRL.MIL
To: Multiple recipients of list UNIX-WIZ <UNIX-WIZ@VM1.NoDak.EDU>
Content-Type: text
Content-Length: 14065

UNIX-WIZARDS Digest          Mon, 07 Sep 1992              V16#002

Today's Topics:
         SCO ODT 1.0 (1.0.0y):  UUCP hangup bugs; uugetty fix?
                            Async IO problem
                          Re: Async IO problem
Intro to comp.unix.wizards - read before posting! (weekly announcement, last
 change: Jul 31 10:30)
                             just asking...
                     Re: SUN/HYUNDAI compatibility
                       Version and Time Stamping
                        Re: A few UNIX questions
                       npasswd - a security hole

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

From: Roy Andrew Crabtree <royc@tcsrtp.uucp>
Subject: SCO ODT 1.0 (1.0.0y):  UUCP hangup bugs; uugetty fix?
Keywords: uucp, uugetty, stty, hupcl, clocal
Date: 3 Sep 92 22:27:23 GMT
To:       unix-wizards@sem.brl.mil


1)  If I use the modem control device (sat tty1A) so that DCD
  is listened to and causes hang up
        a)  stty clocal fails to alter behavior of uugetty
        b) uugetty fns inbound AOK but always talks even with '-r'
        c)  which in turn creates a lock file and stops outbound usage
        d)  I can't 'cu -l tty1A' until DCD is high ...
Newsgroups: comp.unix.wizards
From: rhodesia@wixer.cactus.org (Felix S. Gallo)
Subject: Re: The Problem with UNIX
Followup-To: comp.unix.wizards
Organization: Real/Time Communications
Date: Fri, 13 Nov 92 07:14:11 GMT

so@brownie.cs.wisc.edu (Bryan S. So) writes:

>Concerning "cat a b > b", barnett@crdgw1.ge.com 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                              rhodesia@wixer.cactus.org
----------------------------------------------------------------------------
From: barnett@grymoire.crd.ge.com (Bruce Barnett)
Newsgroups: comp.unix.wizards
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 14:20:45 GMT
	<1992Nov11.210729.11676@cs.wisc.edu>
Reply-To: barnett@crdgw1.ge.com
Organization: GE Corp. R & D, Schenectady, NY

In article <1992Nov11.210729.11676@cs.wisc.edu> so@brownie.cs.wisc.edu (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.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
From: so@brownie.cs.wisc.edu (Bryan S. So)
Newsgroups: comp.unix.wizards
Subject: Re: The Problem with UNIX
Date: 12 Nov 92 23:18:45 GMT
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.

Concerning "cat a b > b", barnett@crdgw1.ge.com 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 <barnett@crd.ge.com> 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
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Subject: Re: The Problem with UNIX
Date: Thu, 12 Nov 1992 02:10:03 GMT
Organization: The Programmer's Pit Stop, Ann Arbor MI

In article <id.NEVU.Z2J@ferranti.com> peter@ferranti.com (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:
mju@mudos.ann-arbor.mi.us   | the hard way, and the easy way.  Let's start
                            | with the hard way."
                            |   - W. Scheider, from a Physics lecture
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: eeide%asylum.cs.utah.edu@cs.utah.edu (Eric Eide)
Subject: Re: The Problem with UNIX
In-reply-to: michael@chpc.utexas.edu's message of Thu, 12 Nov 92 19:37:07 GMT
Organization: University of Utah Department of Computer Science
	<1992Nov11.194557.16258@yarc.uucp>
	<EEIDE.92Nov12120339@asylum.cs.utah.edu>
	<1992Nov12.193707.27532@chpc.utexas.edu>
Date: 12 Nov 92 15:47:22

Michael Lemke (michael@chpc.utexas.edu) 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
eeide@cs.utah.edu  | Buddhist to hot dog vendor: "Make me one with everything."
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: SUN NFS sync
Keywords: sync
Date: 5 Nov 92 23:28:06 GMT
Organization: Auspex Systems, Santa Clara

>It's unclear to me whether these
>NFS implementations support the O_SYNC option or the fsync(2) system
>call.

Some of them may not necessarily support *any* UNIX operations!  They
aren't necessarily running UNIX....

I.e., the server can't support them as an NFS server, as there's no NFS
request that corresponds to "fsync()", nor is there a flag on the NFS
write operation that corresponds to O_SYNC.

O_SYNC, and "fsync()", are *client*-side functions - and, on many
(probably most, if not all) UNIX implementations, they *are* necessary;
the claim that

>The answer is: "You don't need to worry because the NFS protocol
>specifies that all server writes are synchronous." This means that
>your client file write system call won't return until the data is
>actually on disk on the server. No sync is required.

isn't true.  The client file write system call can (as has been
mentioned elsewhere in this thread) simply queue up the write to be done
at some later time to the server.  The write in question will be
synchronous on the server, but it's not necessarily going to be done as
part of the client file write system call.
Newsgroups: comp.unix.wizards
From: troyf@microware.com (Troy Frericks)
Subject: >>TAR file on tape distroyed, are files recoverable?<<
Organization: Microware Systems Corp., Des Moines, Iowa
Date: Tue, 10 Nov 1992 18:43:20 GMT

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: troyf@MICROWARE.COM
Microware Systems Corporation          UUCP: uunet!mcrware!troyf
1900 NW 114th St                      Phone: (515)224-1929
Des Moines, IA 50325-7077               Fax: (515)224-1352
Newsgroups: comp.unix.wizards,comp.unix.misc
From: warsa@polaris.unm.edu (j warsa)
Subject: Re: termcap/terminfo
Date: Tue, 10 Nov 92 18:21:38 GMT
Organization: Universidad de Nuevo Mexico, Alburquerque


I posted a request asking for a termcap entry for AIX hft/aixterm (for which
only sysV terminfo entries are available).

I lost my mbox before I could reply to whoever it was that sent
me the AIX hft termcap entry. Thanks, it works very well for both aixterm
and hft.


-- 
jim warsa
albuquerque
Xref: sparky comp.unix.wizards:4676 comp.unix.shell:4694 comp.unix.misc:4157
From: rsk@gynko.circ.upenn.edu (Rich Kulawiec)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
Date: 14 Nov 92 03:20:51 GMT
Followup-To: comp.unix.wizards
Organization: GSP Whitewater Slalom Racing Team

In article <1992Nov13.094336.2341@aber.ac.uk> btk@aber.ac.uk (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
Newsgroups: comp.unix.wizards
From: mjl@bos.locus.com (Mike Leibensperger)
Subject: Re: RPCGEN
Organization: Locus Computing Corp., Boston Massachusetts USA.
Date: Tue, 10 Nov 1992 18:20:40 GMT

In article <1992Nov9.210917.6951@wdl.loral.com> bmk@box.ssd.loral.com
(Bruce Krawetz) writes:
>
>   Has anybody heard of an rpcgen program that generates
>   pascal source code? (and if so, where can I get it?)

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.

> ---
> bmk@box.ssd.loral.com
> We must learn from our mistakes, so that we may make bigger and better ones.

	mjl
--
Michael J. Leibensperger      "Rats and roaches live by competition under the
Locus Computing/Boston		 laws of supply and demand; it is the privilege
25 Mall Road; Burlington MA	     of human beings to live under the laws of
01803 (617)229-4980 mjl@locus.com       justice and mercy."  -- Wendell Berry
Member of the League for Programming Freedom --- write league@prep.ai.mit.edu
Newsgroups: comp.unix.wizards
From: evansmp@uhura.aston.ac.uk (Mark Evans)
Subject: Re: The Problem with UNIX
Organization: Aston University
Date: Wed, 11 Nov 1992 10:25:55 GMT

mike@pacsoft.com (Mike Stefanik) writes:

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

They might be using OS/2 or a mac possibly as other options.
-- 
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 565 1979 (Home)                     |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |
Newsgroups: comp.unix.wizards
From: aldavi01@starbase.spd.louisville.edu (Arlie Davis)
Subject: Re: The Problem with UNIX
Date: Fri, 13 Nov 1992 09:00:37 GMT
Reply-To: Arlie Davis <aldavi01@starbase.spd.louisville.edu>
Organization: University of Louisville

In <1992Nov13.030529.6207@bilver.uucp> bill@bilver.uucp (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
Newsgroups: comp.unix.wizards