HDTenEightyP/NetNews huggingface dataset:
From: mike@nttor.uucp (Mike Hollander)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 17:04:23 GMT
Organization: Northern Telecom CAC

In article <1992Nov9.172715.16367@cs.wisc.edu> so@brownie.cs.wisc.edu (Bryan S. So) writes:
>
>I am doing research on UNIX command line interface problems.
>I am sure everyone has his/her favorite UNIX troubles, would
>you post or email me what's your favorites?  What should have
>been done by UNIX to resolve that problem in general?
>

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:

1) It is possible to backspace over the prompt.
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.
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.
4) It doesn't seem possible to store macros that could be run with
   a single keypress.
5) The function keys don't do anything and cannot be made to do
   anything on the command line.
6) The insert and remove keys cannot be made to place you in insert
   mode or remove characters.

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

Mike Hollander | mike@nttor.UUCP
Newsgroups: comp.unix.wizards
From: netapp@netcom.com (Network Appliance)
Subject: Re: SUN NFS sync
Keywords: sync
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Fri, 6 Nov 1992 22:30:31 GMT

In article <15358@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>Umm, I don't think it was even the case in 3.x - or 2.x, for that matter
>- that NFS writes were synchronous on the client side.  

Last time I checked, NFS writes were handled very differently in the
SunOS client code as compared with the client code that Sun distributes
to other UNIX vendors who buy NFS from Sun.

In SunOS, the write(2) system call just dirties buffers in memory, and
expects biod's to do the writes when they are able.  In the
distributed NFS, the write(2) system call tries to schedule a biod to
immediately send the write, and if no biod is available, then the
process doing the write(2) does the send itself.

In both cases the write is asychronous with respect to the client
process, but in one case the write is always scheduled immediately
(even if the process must do it itself), whereas in the other case, the
write is only scheduled immediately if a biod is available, otherwise
it may sit in memory for a while.  (This is similar to the difference
between ASYNC and DELWRI on buffers going to disk locally.)

(I can't remember for sure -- it may be that writes less than 8K may
sit in memory for a while in both versions.)

I wonder, Guy, do you remember if older versions of SunOS match the
behavior of the current NFS vendor distribution?  Could that change
have been part of the massive memory whacking around SunOS 4.0?

Dave Hitz		netapp.com
Network Appliance	(408) 562-1906
Newsgroups: comp.unix.wizards
From: parson@pop.stat.purdue.edu (Eric Parson)
Subject: Any TeX (compilation) Gurus out there?
Keywords: TeX, make 
Organization: Purdue University Statistics Department
Date: Wed, 11 Nov 1992 20:28:46 GMT

I'm running out of thoughts of where to send up distress flares.  Hopefully
there's a hopeful hint or five out there somewhere.

I'm in the process of installing the complete TeX distribution on my
SPARC 2 station.  To make a long story short, after a couple of failures
along the 'make' path, I've run up against one that I can't seem to overcome.
I've managed to get to the point where MetaFont is creating the 'plain'
fonts, and the 'make' bogs down.  After some false starts, I manage to 
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.  
	I would greatly appreciate any input someone out there could/would 
provide about even how to attack the problem, I would greatly appreciate
it.  (Cannonization is probable if you can actually help me nuke this prob.
:-)  )  Thanks in advance for any help you can provide.

			Eric T. Parson
				parson@pop.stat.purdue.edu
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: 10 Nov 92 14:18:06 GMT
Followup-To: comp.unix.wizards
Organization: GSP Whitewater Slalom Racing Team

In article <1992Nov9.172715.16367@cs.wisc.edu> so@brownie.cs.wisc.edu (Bryan S. So) writes:
>Does anybody know of excellent papers in this area?  I know 
>about Norman's "The Trouble with UNIX".

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'd suggest Rob Pike's 'cat -v considered harmful' as an excellent
starting point.

---Rsk
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: The Problem with UNIX
Organization: Xenix Support, FICC
Date: Tue, 10 Nov 1992 20:23:41 GMT

In article <1992Nov9.172715.16367@cs.wisc.edu> so@brownie.cs.wisc.edu (Bryan S. So) writes:
> I am doing research on UNIX command line interface problems.
> I am sure everyone has his/her favorite UNIX troubles, would
> you post or email me what's your favorites?  What should have
> been done by UNIX to resolve that problem in general?

UNIX isn't an entity that can *do* anything. A better question would be
what could (Bell Labs, Thompson, Ritchie, ...) have done to make UNIX
easier to use? Well, Bell Labs could have bought all the UNIX people
dumb terminals instead of teletypes, even if that was hideously expensive,
so that they wouldn't have as much of an incentive to shorten command lines.
Have you ever worked on a genuine ASR33?

> To start the discussion, consider the following problems:

PIP FILE.=FILE.

PIP FILE.*;*/DE

PIP LP:=[1,54]PIP.COM

>     Sending binary file should be uuencoded first.

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

>     This is a general type conflict problem.

No, it's an error-checking problem.

These aren't "UNIX" problems. These are general "Customer Engineering"
problems. UNIX is pretty good by the general standards of operating systems
of the time. The problem is that AT&T/USG/USL/Univel/whoever it is this week
has never sat down and done a thorough study of what is needed to "flatten"
the user interface. It's 1992, not 1972.

The most important problem, in my opinion, you never even mentioned:

	cat: cannot open /blog/crottled/greeps

What does this mean? /blog doesn't exist? Permissions are wrong? Some
system is down? What?

	/blog/crottled/greeps: Network I/O error.
	cat: Can't open input file.

Just (a) fixing all applications so they call perror on failure, and (b)
cutting down on the overloading of error messages, would do wonders.
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
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?
Newsgroups: comp.unix.wizards
Subject: Re: Detecting if running under chroot
From: oleg@gd.bu.edu (Oleg Kibirev)
Date: 9 Nov 92 01:57:47 PST
Organization: Computer Science Departement of California State University in Fresno

In article <mark.721121538@coombs> mark@coombs.anu.edu.au (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?

What about checking i-node number of / ? Just checked a few systems and it appears
to be the same:

gd:~> ls -di /
     2 //

Of course, this  can miserably fail with  NFS where root  is  actually
/export/root. What is actually checked is weather current root == root
of *some*  filesystem. Why would   program need to   check if  it runs
chrooted?

Oleg

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: scott@yarc.uucp's message of Wed, 11 Nov 1992 19:45:57 GMT
Organization: University of Utah Department of Computer Science
	<aldavi01.721333614@starbase.spd.louisville.edu>
	<1992Nov11.194557.16258@yarc.uucp>
Date: 12 Nov 92 12:03:39

Scott Beckstead (scott@yarc.uucp) 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
eeide@cs.utah.edu  | Buddhist to hot dog vendor: "Make me one with everything."
Newsgroups: comp.unix.wizards
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: The Problem with UNIX
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Wed, 11 Nov 1992 15:08:28 GMT

In article <1452@pacsoft.com>, mike@pacsoft.com (Mike Stefanik) writes:
> 
> 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? :-)
> 

Well I'm doing my best to avoid it.  I'm using Byron's rc and the Plan 9
editor sam (and have done so for more than a year).  Lately we have short
term Plan 9 style backups:

    prl313 dump; cd 9211/10/udir/boyd/work/ftpnfs
    prl313 ftpnfs; ls -ltr
    total 16
    -rw-r--r--  1 boyd          766 Nov  9 14:01 README
    -rw-r--r--  1 boyd         1940 Nov  9 19:31 Makefile
    -rw-rw-r--  1 boyd         7190 Nov  9 23:51 ftpnfs.1
    drwxrwxr-x  3 boyd          512 Nov 10 03:49 src
    drwxrwxr-x  2 boyd          512 Nov 10 03:49 doc
    drwxrwxr-x  2 boyd          512 Nov 10 03:49 test
    drwxrwxr-x  2 boyd          512 Nov 10 03:54 mips
    drwxrwxr-x  2 boyd          512 Nov 10 03:54 vax

So there's (some) of the work I did a day or so ago.

Hell, I've even been hacking VMS:

    $ start/queue/on=prlvms:: eve


Boyd Roberts			boyd@prl.dec.com

``Not only is UNIX dead, it's starting to smell really bad.''  -- Rob Pike
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: aldavi01@terra.spd.louisville.edu (Arlie Davis)
Subject: Re: The Problem with UNIX
Date: Mon, 9 Nov 1992 18:26:54 GMT
Reply-To: Arlie Davis <aldavi01@starbase.spd.louisville.edu>
Organization: University of Louisville

In comp.unix.misc you write:

> I am doing research on UNIX command line interface problems.
> I am sure everyone has his/her favorite UNIX troubles, would
> you post or email me what's your favorites?  What should have
> been done by UNIX to resolve that problem in general?

Are you sure you are researching the command line interface?  None of your
examples below seem to suggest so.

> Does anybody know of excellent papers in this area?  I know 
> about Norman's "The Trouble with UNIX".

> To start the discussion, consider the following problems:

>     cat a b > b

>     This is a general problem of trying to modify the input
>     file.

This has nothing at all to do with the command line interface.  This is simply
an *error* in user semantics.  What should cat do?  Stick in a feedback loop?
No, this is definitely an error on the user's side.

>     rm -filename_with_a_hyphen

>     This is a general problem of name clash (clashing filename
>     with command options.)

True, but it is a trivial one.  *All* UNIX filenames can specified explicitly
with a full pathname (such as "rm /tmp/foo/bar/-filename_with_a_hyphen" or
"rm $PWD/-filename_with_a_hyphen"), or as a relative directory, starting with
the parent directory ".." or the current directory "." (such as
"rm ./-filename_with_a_hyphen").

Also, again, this has nothing at all to do with the command line interface,
the "shell".  How programs interpret their argument vector is entirely up
to them.  The shell only passes on what the user types.

>     mail somebody < a.out

>     Sending binary file should be uuencoded first.  This is a
>     general type conflict problem.

Again, this is an error on the *user's* side.  This has nothing to do with the
shell!  Yes, you could create a mail script wrapper that checked the magic cookie
of the file being sent (see file(1)), and uuencoded if necessary.  But this is
completely different from the shell.

> Bryan So
-- 
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null
From: cecchinr@gehrig.cs.rpi.edu (Ron Cecchini)
Newsgroups: comp.unix.wizards
Subject: Q: Proper client/server protocol w.r.t. socket read/writes
Date: 6 Nov 92 23:06:24 GMT
Article-I.D.: rpi.0ck1+wp
Organization: Rensselaer Polytechnic Institute, Troy, NY

Hi all - I figured it was ok to post this here, since it is a socket question.

Basically, I just want to know what is the proper protocol to use when
I am simultaneously reading/writing from/to a socket.  I am looking at
some client/server code that a friend wrote, and every time she does a
write, she immediately does a read to acknowledge that the info got to 
the other side - I'll draw a picture:

Client: Write "info"			Server: Read "info"
						Write "received info"
Client: Read - if equals "received info" 
               then do the next write
               else error

You get the picture... My question is: is this the standard way of doing
this?  It seems like you double the processing time by having to read
for every write, and vice-versa.  She says that when she didn't do this,
her application crashed because of some kind of "imbalance".

I just want to know if this is what I have to and, if not, then what is the
right way.

Thanx a mil,
Ron
Newsgroups: comp.unix.wizards,comp.unix.shell
From: phart@heineken.tuc.nrao.edu (Paul O. Hart)
Subject: Re: The Problem with UNIX
Organization: National Radio Astronomy Observatory
Date: Sat, 14 Nov 1992 02:00:19 GMT

Quoted from apl@world.std.com (Anthony P Lawrence) in <Bxo6sn.FtC@world.std.com>:
->Personally, I don't want a shell that thinks very much about what
->I might have meant.
->
->		Tony   apl@world.std.com
->
->Lawrence & Clark, Inc		(617) 762-0707	(206) 323-2864
->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   {>  {>  {>  {>  {> |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=^=-=^=-=^=-=^=-=^=-=
Xref: sparky comp.unix.wizards:4629 comp.unix.shell:4656 comp.unix.misc:4121
From: arne@nats.informatik.uni-hamburg.de (Arne Ludwig)
Subject: Re: Q: Proper client/server protocol w.r.t. socket read/writes
Organization: University of Hamburg, FRG
Date: 10 Nov 92 17:03:19 GMT

cecchinr@gehrig.cs.rpi.edu (Ron Cecchini) writes:
>every time she does a
>write, she immediately does a read to acknowledge that the info got to 
>the other side

>She says that when she didn't do this,
>her application crashed because of some kind of "imbalance".

You don't supply enough information, but this suggests to me that she
might be using a stream socket and variable length messages.

If she's not acknowledging the individual packets, this may, and almost
always does, mean that some messages get mixed up with previous ones,
because streams are not "packetized".

You may think of avoiding this problem by using datagram sockets, but
unfortunately most Unices don't give you reliable, sequenced delivery
on datagrams sockets, so you would need the acknowledge after all.

A very simple solution is to use fixed packet lengths, or transmitting
length information with each packet.
--
Arne Ludwig
ludwiga@informatik.uni-hamburg.de			arne@rrzbu.hanse.de
From: postmaster@tintin.csl.sni.be
Newsgroups: comp.unix.wizards
Subject: smtp mail failed
Date: 12 Nov 92 07:01:28 GMT

Your mail to magellan is undeliverable.
---------- diagnosis ----------
---------- unsent mail ----------
From UNIX-WIZARDS Sun Sep  6 15:15:17 EST 1992 remote from BRL.MIL remote from tintin
Received: from BRL.MIL by tintin.csl.sni.be; Thu, 12 Nov 1992 07:08 MET
Received: by snibru.uucp (/\==/\ Smail3.1.25.1 #25.4)
	id <m0mpWfO-00012FC@snibru.uucp>; Thu, 12 Nov 92 06:00 MEZ
Received: from vm1.NoDak.edu by ub4b.buug.be (5.65c/ub4b_02)
	id AA03797; Thu, 12 Nov 1992 02:22:53 +0100
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP V2R2)
   with BSMTP id 0227; Wed, 11 Nov 92 19:22:09 CST
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 5443; Wed, 11 Nov 92 19:22:06 CST
Message-Id: <199211120122.AA03797@ub4b.buug.be>
Date:         Sun, 6 Sep 1992 15:15:17 EST
Reply-To: UNIX-WIZARDS@BRL.MIL
From: "The Moderator (Mike Muuss)" <Unix-Wizards-Request@BRL.MIL>
Subject:      UNIX-WIZARDS Digest  V16#001
X-To:         UNIX-WIZARDS@BRL.MIL
To: Multiple recipients of list UNIX-WIZ <UNIX-WIZ@VM1.NoDak.EDU>
Content-Type: text
Content-Length: 26253

UNIX-WIZARDS Digest          Sun, 06 Sep 1992              V16#001

Today's Topics:
                ASYNCHRONOUS FILE PRESENCE NOTIFICATION
            Re: How do I remove a directory with no parent?
           Re: Implementation of Sys V. based message queues
                           Re: Disk bad block
                  Re: STREAMS M_ERROR Message problem
                      Question on COFF file format
                    Re: Question on COFF file format
                        random passwd generator
                      Re: random passwd generator
                            Re: Passing FIDs
                          Superblock question
                             UUCP-question

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

From: Kunal Singh <ksingh@passion.fia.dmg.ml.com>
Subject: ASYNCHRONOUS FILE PRESENCE NOTIFICATION
Keywords: UNIX FILE
Date: 1 Sep 92 14:26:47 GMT
To:       unix-wizards@sem.brl.mil

I'm trying to write a program which will check a certain directory for incoming
 files.  I want this program to be interrupt-driven such that as soon as a file
 is put into this directory, my program is signaled and can process the file.
Newsgroups: comp.unix.wizards
From: pnarayan@cs.tamu.edu (P S Narayan)
Subject: system call write
Organization: Computer Science Department, Texas A&M University
Date: Fri, 13 Nov 1992 16:48:55 GMT

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
pnarayan@cs.tamu.edu

Xref: sparky comp.unix.wizards:4596 comp.unix.shell:4630 comp.unix.misc:4092
From: lyndon@unbc.edu (Lyndon Nerenberg)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
Date: 10 Nov 92 21:22:20 GMT
Followup-To: comp.unix.shell
Organization: University of Northern B.C.

boyd@prl.dec.com (Boyd Roberts) writes:
> >   Compared to what, oh great OS guru?

> Compared to Plan 9.

I'm not very familiar with Plan 9. How does rc address the problems the
original poster detailed?