HDTenEightyP/NetNews huggingface dataset:
From: andy@research.canon.oz.au (Andy Newman)
Subject: Re: The Problem with UNIX
Organization: Canon Information Systems Research Australia
Date: Fri, 13 Nov 1992 04:32:46 GMT

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

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

-- 
Andy Newman (andy@research.canon.oz.au)
Newsgroups: comp.unix.wizards
From: weltman@parc.xerox.com (Rob Weltman)
Subject: Reinitializing standard streams
Keywords: streams, io
Reply-To: weltman@parc.xerox.com
Organization: Xerox PARC, Palo Alto, CA
Date: Fri, 6 Nov 1992 16:40:46 GMT


  If a program has arbitrarily reassigned stdout, stdin,
and stderr (with freopen), is there a straightforward way
to restore the initial conditions? Or do you have to reopen
them on /dev/tty, setting stderr unbuffered? If the latter,
what other information should be saved before calling freopen,
to reset the initial state later on?
---


-----------------------------------------
Rob Weltman
weltman@parc.xerox.com
phone (415)-813-7477   fax (415)-813-6792
-----------------------------------------
From: mohan@Auspex.COM (Mohan Srinivasan)
Newsgroups: comp.unix.wizards
Subject: Re: SUN NFS sync
Keywords: sync
Date: 9 Nov 92 18:43:17 GMT
Organization: Auspex Systems, Santa Clara

In article <1992Nov6.223031.13503@netcom.com> netapp@netcom.com (Network Appliance) writes:
>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.
>

Actually, even in SunOS (both 4.X and 5.X), if the write rounds up to a
8K chunk, the write is scheduled to the biod's immediately (ie. if there is
a biod available, the write'ing process hands over the write to it. 
Otherwise, if there's no free biod available, the write is done
by the writing process itself - this is 4.x behavior, in 5.x an async
write is always queued up to be picked up by the biod threads).

Scheduling the write is done by the function in the segmap driver code
that releases the mapped (segkmap) segment. It calls VOP_PUTPAGE() with
the flags that were passed to itself. (So, it handles cases like ASYNC,
INVAL, DONTNEED etc).

However, you're right in that if the write is < 8k, then it just dirties
the page(s).

-- 
===============================================================================
Ram Mohan Srinivasan
mohan@auspex.com
===============================================================================
From: envwpk@epb2.lbl.gov (Werner P. Keilholz)
Newsgroups: comp.unix.wizards
Subject: How to set Return PATH ?
Date: 5 Nov 1992 14:47:41 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Distribution: world
Reply-To: envwpk@epb2.lbl.gov (Werner P. Keilholz)
NNTP-Posting-Host: 128.3.12.39

Asked the following question in comp.unix.questions, but apparently it is
so wizardly, nobody replied. So I try here...

Sorry, I posted this question before, but in the meantime our system 
broke down, so I didn't get any replies. I appologize to everybody 
who tried to answer and got an error of the style 'service not 
available...'.

My problem is, how to configure the Return-Path used by the mailer 
when it is creating headers. In principle, my mailer works fine, i.e. 
I can send and receive mail via the net. However, if people try to use 
the REPLY function of their mailers to answer mail comming from our site, 
the replies bounce, because the mailer generated a wrong 'RETURN-PATH:' 
line. 

I checked the man on sendmail, and it says the configuration is done in 
/etc/sendmail.cf .  In this file I indeed found a line like
RETURN PATH: <$g>

Great. But where is $g defined ???  Of course, I could put in some 
constant string, but I only want to receive the replies to my own mails,
not *everybody's* !

Thanks for any kind of hint !

Werner

----------------------------------------------------------------------------
Werner Keilholz                     EMAIL: werner@CSTB.FR                 or
CSTB Sophia Antipolis                      CSTBSOP!werner@CORTON.INRIA.FR or
BP 209                                     envwpk@epb2.lbl.gov
06904 SOPHIA ANTIPOLIS                     Warning: mail header replies
F R A N C E / United States of Europe               to CSTB don't work!

  It's not the holy Grail - it's ISO !
Xref: sparky comp.unix.wizards:4672 comp.unix.shell:4690 comp.unix.misc:4151
From: btk@aber.ac.uk (Ben Ketteridge)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 09:43:36 GMT
Organization: The Cottage of the 2 Bears, Aberystwyth.

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! |      btk@aber.ac.uk       |
+--------------+-------------------------------+---------------------------+
From: davidb@muppet.bt.co.uk (David Baboulene DND3)
Newsgroups: comp.unix.wizards
Subject: SCCS ID Keywords problem
Date: 12 Nov 92 08:28:17 GMT
Reply-To: davidb@muppet.bt.co.uk
Organization: British Telecom Research Labs.


Hi Chaps/Chappettes,

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

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

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

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

Thanking you in advance of any help you can give,

Cheers,


David Baboulene (davidb@muppet.bt.co.uk)

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

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

                Love thy neighbour; tune thy piano
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: Fri, 13 Nov 1992 18:08:04 GMT

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

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

cat has done that for a long time.


Boyd Roberts			boyd@prl.dec.com

``Not only is UNIX dead, it's starting to smell really bad.''  -- Rob Pike
Newsgroups: comp.unix.wizards
From: zoron@en.ecn.purdue.edu (Soren M Burkhart)
Subject: Problem with Window to Window commands.... HELP!
Organization: Purdue University Engineering Computer Network
Date: Thu, 12 Nov 92 15:59:09 GMT


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


   thanks,

      Soren


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

  Soren Burkhart
  Purdue University
  AI & Robotics
  EMAIL: zoron@en.ecn.purdue.edu
From: valdis@vttcf.cc.vt.edu (Valdis Kletnieks)
Newsgroups: comp.unix.wizards
Subject: Re: Process 'purge' revisited.. Unix missing this?
Date: 10 Nov 92 09:52:55 GMT
Organization: Virginia Tech, Blacksburg, VA

In article <TPAQUETTE.92Nov6132758@gumby.ita.lgc.com> tpaquette@ita.lgc.com (Trevor Paquette) writes:
> All the responses I have recieved have all said exactly what I thought.
>It is impossible to 'purge' a process witing on a hung device.
>
> Is this a deficency in Unix? Should it be added? Will I ever win the
>lottery?

No, it's a deficiency in operating systems in general.

Now let's look at what happens:

You have a "process"/"task"/whatever you want to call it that initiates
an I/O transfer to a device.  Said device mysteriously flames out
before the transfer completes.  You're sitting there with a process
that has some buffers locked in memory as a target for the I/O.

What should you do?

You can't just kill the process and free the buffers - that device might
wake up and complete the I/O over where the buffers USED to be.
Unless you're willing to bet the system that you have managed to FOR SURE
abort an in-progress transfer, you have to keep enough state around
so that if it DOES complete, you won't get torched.

SImply pretending the I/O is gone loses too - the process may get
confused, and if the I/O *does* complete, you're torched.

Killing the process and not freeing the buffers gets interesting, as
you have to then find some way of dealing with the buffers - most
operating systems kind of make an assumption that allocated real
memory *belongs* to somebody - so a "kill the process and free all but
these 960 bytes" gets interesting.  

And of course all sorts of OTHER warts arise in the real world.. ;)

Feel free to propose what you think it should do - and remember in
your design to address all the failure modes (Heck, we only *get*
into this situation if something has failed already)....

				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech
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:28:38 GMT

Boyd Roberts sigged:
> ``Not only is UNIX dead, it's starting to smell really bad.''  -- Rob Pike

Jawaid Bazyar asked:
> >   Compared to what, oh great OS guru?

Boyd Roberts response:
> Compared to Plan 9.

Plan 9 is currently still in the preemie ward. When I can go out and buy a
copy of Plan 9 with all the installation tools I get with System V, then
I'll be able to take a look at it. But today, even if I could get a copy of
Plan 9 it wouldn't run on anything I have access to. And the installation,
based on the Plan 9 docs I've got, is a real pain.

I'd love to try it, though...
-- 
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
From: troyf@microware.com (Troy Frericks)
Subject: Re: >>TAR file on tape distroyed, are files recoverable?<<
Organization: Microware Systems Corp., Des Moines, Iowa
Date: Wed, 11 Nov 1992 22:23:08 GMT

In article <1992Nov10.184320.5998@microware.com> troyf@microware.com (Troy Frericks) writes:
>I have a tape that contained a large 'tar' file.  The data is not
>replaceable.  The data that is needed is at the end of the tar
>file, but it is inaccessable because the wrong parameter was
>passed to tar when attempting to retrieve it.  The 'c' for
>create, rather than 'x' for eXtract was passed, which caused
>tar to write a tiny tar file over the beginning of the
>larger one.
>
>Any hints on how to retrieve files from a large tar file once
>the beginning of the tar file has been distroyed?
>
>-
>Troy Frericks                      Internet: 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

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

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

-
Troy Frericks                      Internet: 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
Xref: sparky comp.unix.wizards:4649 comp.unix.shell:4669 comp.unix.misc:4136
From: barr@pop.psu.edu (David Barr)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
Date: 13 Nov 92 03:16:11 GMT
Organization: Penn State Population Research Institute

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

You mean like getopt(3)?

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

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

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

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

% weather nov 15

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
Newsgroups: comp.unix.wizards
From: nll@cbnewsb.cb.att.com (neal.l.leitner)
Subject: TTYDEFS Help!
Organization: AT&T
Date: Thu, 12 Nov 1992 21:15:52 GMT

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

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

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

Neal Leitner
..att!emdbl1!nll

Xref: sparky comp.unix.wizards:4572 comp.unix.shell:4601 comp.unix.misc:4071
From: so@brownie.cs.wisc.edu (Bryan S. So)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: The Problem with UNIX
Date: 9 Nov 92 17:27:15 GMT
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.


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?

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.


    rm -filename_with_a_hyphen

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


    mail somebody < a.out

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


Bryan So
From: mark@coombs.anu.edu.au (Mark)
Newsgroups: comp.unix.wizards
Subject: Detecting if running under chroot
Date: 7 Nov 92 07:32:18 GMT
Organization: Australian National University
NNTP-Posting-Host: 150.203.76.2
Organisation: Wassat?!


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?

Or is there some call that returns your *real* directory.

Mark
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: mat@mole-end.matawan.nj.us
Subject: Re: The Problem with UNIX
Summary: What is `getting it right'?
Organization: :
Date: Thu, 12 Nov 1992 22:14:05 GMT

In article <BxKM7p.724@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes:
> In article <id.NEVU.Z2J@ferranti.com> peter@ferranti.com (peter da silva) writes:
> >>     Sending binary file should be uuencoded first.

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

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

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

This user says `Plugh!'

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

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.unix.wizards
From: cons@mercury.cern.ch (Lionel Cons)
Subject: Re: Detecting if running under chroot
Organization: CERN, European Research Center for Particle Physics
Date: Mon, 9 Nov 1992 09:04:04 GMT

I know a way to see if I run under chroot on my OS (HP-UX) and I think
it should work on many different platforms: the inode number of / is
always 2, so 'ls -id' will tell me...
--

Lionel Cons

+------- CERN - European Laboratory for Particle Physics -------+
| E-mail: cons@dxcern.cern.ch                                   |
| Earth-mail: CN/SW/WS, CERN, CH-1211 GENEVE 23, Switzerland    |
| Phone: +41 22 767 49 13              Fax: +41 22 767 71 55    |
+---------------------------------------------------------------+
Newsgroups: comp.unix.wizards
From: aldavi01@rigel.spd.louisville.edu (Arlie Davis)
Subject: Re: The Problem with UNIX
Date: Mon, 9 Nov 1992 23:20:00 GMT
Reply-To: Arlie Davis <aldavi01@starbase.spd.louisville.edu>
Organization: University of Louisville

In <1992Nov9.215307.11145@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:

> How about the fact that it is default for mv to overwrite existing files?
> It's way too easy to type something like

> 	mv <pattern>

If you find this peevesome, do this: "alias mv='mv -i'".  It's in the fine
manual pages.

-- 
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null
Newsgroups: comp.unix.wizards
From: mstowski@seas.gwu.edu (Mike Mstowski)
Subject: Getty Source Code
Keywords: GETTY SOURCE CODE
Organization: George Washington University
Date: Thu, 12 Nov 1992 11:57:43 GMT

I have to write a getty program for SCO UNIX and possibly for other unix
systems at a later time.  Does anyone have any source code to do this that
I might look at.  The time savings would be great.
Any help is greatly appreciated!
Thanks in advance!
mstowski@seas.gwu.edu