Mail not delivered yet, still trying

SMTP MAILER postmaster at sandia.gov
Fri Oct 13 03:13:09 AEST 1989


 ----Mail status follows----
Have been unable to send your mail to <omalley%hotair at decwrl.dec.com>,
will keep trying for a total of three days.
At that time your mail will be returned.

 ----Transcript of message follows----
Date: 12 Oct 89 03:44:00 MDT
From: unix-wizards at BRL.MIL
Subject: UNIX-WIZARDS Digest  V8#090
To: "omalley" <omalley%hotair at decwrl.dec.com>

Return-Path: <incoming-unix-wizards-request at sandia.gov>
Received: from SEM.BRL.MIL by sandia.gov with SMTP ; 
          Thu, 12 Oct 89 03:34:01 MDT
Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa20946; 12 Oct 89 2:56 EDT
Received: from sem.brl.mil by SEM.BRL.MIL id aa20799; 12 Oct 89 2:45 EDT
Date:       Thu, 12 Oct 89 02:45:23 EST
From:       The Moderator (Mike Muuss) <Unix-Wizards-Request at BRL.MIL>
To:         UNIX-WIZARDS at BRL.MIL
Reply-To:   UNIX-WIZARDS at BRL.MIL
Subject:    UNIX-WIZARDS Digest  V8#090
Message-ID:  <8910120245.aa20799 at SEM.BRL.MIL>

UNIX-WIZARDS Digest          Thu, 12 Oct 1989              V8#090

Today's Topics:
                               Re: ls -A
              How Do I Check Code Compilation Consistency?
                               Re: MUSBUS
          Re: ls -A - should be easier than this (and it was)
              Re: Can directory files have holes in them ?
                       Re: UNIX history made easy
            vmunix: stropen: out of streams in SunOS 4.0 ??
            Re: UNIX-like crypt function/crypt() outside USA
              Re: Job Control (a la csh/ksh) from within C
                       Re: UNIX history made easy
             A little salve (Re: Is there an FSDB Manual?)
                       Re: UNIX history made easy
                    timeout command in shell script!
              Re: Job Control (a la csh/ksh) from within C

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

From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: ls -A
Date: 11 Oct 89 07:08:02 GMT
To:       unix-wizards at sem.brl.mil

In article <17118 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F. Haugh II) writes:
>Xenix is -not- UNIX.  BSD 4.x is -not- UNIX.  Nor are the remainder
>of the things listed above which can't legally call themselves UNIX.

BSD predates the SVID, SVVS, and rules about calling the modified AT&T
software (that's what BSD basically is) "UNIX".

The latest release of Xenix is called UNIX System V Release 3.2.

Besides, recall what Humpty Dumpty said about who's master..

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

From: Michael D Stiber <stiber at maui.cs.ucla.edu>
Subject: How Do I Check Code Compilation Consistency?
Date: 11 Oct 89 06:40:09 GMT
Sender: news at cs.ucla.edu
To:       unix-wizards at sem.brl.mil


We have a rather large software project, in which there are many files
divided among several directories, each directory with its own
Makefile.  Definitions for CFLAGS, etc are made in a main Makefile,
and passed along to subdirectory Makefiles.  The problem is this:
there are several compilation options that one may choose, and we must
be sure that all files are compiled with the same options.  To
complicate things, if different files are compiled with different
options, no obvious errors may result -- the errors are quite likely
to be very subtle, but fatal nonetheless.

To complicate things even further, this project will be used by others
with less knowledge of the inner workings of the code.  They will most
likely be adding their own modules to it.  Any errors introduced by
inconsistent compilation will be very difficult for them to track down
(difficult for us to track down, even).

So, is there any good way to do some sort of consistency checking,
either at link time or run time?  One idea I had was to have a header
file that is included in every source file, which would stick a static
string in the object code that says the file name and the compilation
options that were used.  Then, at run time, the program could grep for
all of those strings in its own object code, and check to make sure
they were consistent.  Is that a good approach?  A stupid, clumsy
approach?  An approach unlikely to be portable from one version of
UNIX to another?  Any better ideas?

I'd really appreciate any pointers or ideas that anyone could give me.
Thanks!!
			    Michael Stiber
   stiber at cs.ucla.edu                  UCLA Computer Science Dept.
   ...{ucbvax,ihpn4}!ucla-cs!stiber    Machine Perception Laboratory
                                 3564 Boelter Hall,Los Angeles, CA 90024

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

From: Ken McDonell <kenj at yarra.oz.au>
Subject: Re: MUSBUS
Date: 11 Oct 89 04:59:33 GMT
To:       unix-wizards at sem.brl.mil

In article <4034 at phri.UUCP> roy at phri.UUCP (Roy Smith) writes:
>
> 	A computer salesman was talking to me this morning about something
> called MUSBUS.  I vaugely remember hearing about it being some sort of
> benchmark for multi-user Unix systems, simulating some sort of "average"
> multiuser workload.  Anybody know anything about it? ...

MUSBUS (Monash University Software for Benchmarking Unix Systems) is
a synthetic multi-user benchmark in which the user workload profile
is intended to be one of the input parameters.  It was originally designed
to assist in comparative performance evaluations during equipment
acquistions.

Here is the standard "glossy" availability blurb I send out ...

    The MUSBUS source is in the public domain, distributed via the
    USENET newsgroup comp.sources.unix as follows
	    Version 5.0	volume 11, issues 29-32
	    Version 5.2	volume 12, issues 72-74
    You will need both, as the 5.2 distribution is an upgrade kit that
    assumes you already have Version 5.0.

    There is a MUSBUS mailing list that is used to distributed an infrequent
    Newsletter containing items of interest to those using MUSBUS, or related
    performance analysis tools.  If you'd like to join the mailing list
    send an e-mail request to kenj at yarra.oz.au

I am currently working on Version 6.1 with some scaling and normalization
enhancements, and additional "canned" workloads.

> ... Is there some
> repository of MUSBUS ratings for various machines somewhere?

Yes, I have them.  I do not distribute them, because

1. Unlike some others (dhrystone, AIM User Rating, ...) I have no faith
   in ``single figure of merit'' numbers for serious performance analysis.

2. The default workload will help you select the correct machine for Monash's
   Computer Science Department, circa 1982.  The relevance for others is
   questionable.

3. Unlike the pedlars of some other commercially available performance
   numbers, I am not interested in old numbers.  Today's Unix version and
   C compiler will deliver very different performance to yesterday's,
   even from the same vendor and on the same hardware (R&D folks do address
   performance issues in shipped product!).

4. If you are interested in multi-user performance for a particular
   application profile, build a workload and ask the vendors to run MUSBUS
   using YOUR workload.  Software engineering and portability issues have
   been addressed to the extent that this is not an onerous request.
   
The SPEC members have expressed some interest in MUSBUS, anyone from
there care to comment?

Disclaimer: I now work for Pyramid Technology, not Monash University, but
	    as always I speak for myself alone.

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

From: Dick Dunn <rcd at ico.isc.com>
Subject: Re: ls -A - should be easier than this (and it was)
Date: 11 Oct 89 05:34:56 GMT
To:       unix-wizards at sem.brl.mil

General discussion is about trying to get ls to show files beginning with
 ., without getting . and ..

I remember that V7 *did* give files with names beginning with ".".  I
remember that this went away somewhere down the road...BSD let us ask for
it with -A, which Sys V doesn't implement.  I also remember a peek into the
Sys V source at some point which said that there's a compilation option to
ls which will give the dot-prefixed names.

so...mutter, grumble...I used to have it, then I could ask for it, now it's
there but I can't get at it.  Is dis progress?  I dunno, I don' tink so.
-- 
Dick Dunn     rcd at ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.

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

From: John Bruner <bruner at uicsrd.csrd.uiuc.edu>
Subject: Re: Can directory files have holes in them ?
Date: 11 Oct 89 13:15:34 GMT
Sender: News <news at ux1.cso.uiuc.edu>
To:       unix-wizards at sem.brl.mil

In article <20044 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>The original question was why dump is careful not to look at holes
>in directories.  The only possible answer is `paranoia'.

The paranoid code in dump and the kernel was added because of a
problem I ran into at Purdue on either a V7 PDP-11 or 4.1BSD VAX
(probably an 11/70) several years ago.  A hardware problem caused
a block pointer in a directory inode to be zeroed.  (I do not
remember the exact circumstances, except that it was a hardware
problem and it did not totally destroy the disc.)  "fsck" passed
the filesystem without a complaint, but any attempt to access the
directory (which I recall was something innocuous like "/usr/bin")
caused a panic.

In those days I believe that namei() did something like

	bp = bread(ip->i_dev, bmap(ip, lbn, B_READ));

The bug was that namei() didn't check whether bmap() returned -1
because holes in directories were "impossible".  My fix was to report
the hole on the console and allocate a new block if the filesystem
was mounted read/write; otherwise, it just skipped to the next block.
As I recall, "fsck" had code which checked for holes in files, but it
was commented out.  I turned on the check for directories.
I sent mail to Berkeley, and they integrated these changes into the
4.2BSD filesystem code (although they removed the code which filled
in the hole).
--
John Bruner	Center for Supercomputing R&D, University of Illinois
	bruner at uicsrd.csrd.uiuc.edu	(217) 244-4476	

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

From: ari at kolmogorov.physics.uiuc.edu
Subject: Re: UNIX history made easy
Date: 11 Oct 89 16:41:18 GMT
Nf-ID: #R:rpp386.cactus.org:17085:kolmogorov:8600002:000:345
Nf-From: kolmogorov.physics.uiuc.edu!ari    Oct 10 04:29:00 1989
To:       unix-wizards at sem.brl.mil


In my field, physics, I don't know every Nobel prize lauriate,
(sure, I know many, but not near most).  There are some
who won, that I can't remember what for, and then there
are some physicist who didn't win, that I think have.  However,
this doesn't seem to interfere with doing physics.  Oh well, 
I guess I'm not a scientist after all.

ari

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

From: Eric Ho <eho at clarity.princeton.edu>
Subject: vmunix: stropen: out of streams in SunOS 4.0 ??
Date: 11 Oct 89 17:34:15 GMT
Sender: news at brunix.uucp
To:       unix-wizards at sem.brl.mil

Has anyone out there seen such things before ?

I keep getting these "vmunix:  stropen: out of streams" messages on my Sun-4
server. We are running SunOS 4.0 on the entire net.  The server is a
Sun-4/280S-24 running GENERIC kernel. It usually happens when we've a lot of
users login to the server or when the load of the server is high.  The server
has a standard Eagle & a Hitachi DK15 -- both of them hooked off a Xylogics
451.  Other things on the server include a 1/4-inch scsi cartridage tape drive
and an ALM-1 board.  And I've already allocated over 35 meg of swap for the
server.

My initial guess is that there is something weird with the kernel since there
are ample of swap space & ram (24 meg) on this server.

Here is an excerpt from /var/adm/messages :-
==========================================
Oct 11 11:46:46 clarity vmunix: stropen: out of streams
Oct 11 11:47:40 clarity vmunix: stropen: out of streams
==========================================

Any pointers/info would be much appreciated.
--

Eric Ho  
Princeton University
eho at confidence.princeton.edu

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

From: "Mark J. DeFilippis" <mark at promark.uucp>
Subject: Re: UNIX-like crypt function/crypt() outside USA
Date: 11 Oct 89 04:01:29 GMT
Followup-To: poster
Keywords: crypt unix NSA export
To:       unix-wizards at sem.brl.mil

In article <750 at imuse.uucp>, ed at imuse.uucp (Ed Braaten) writes:
> Funny thing!  The SCO Xenix machine I play on at home has the crypt()
> facility on it, and I live in Dachau, (West) Germany.  How did it get 
> here?  I bought my Xenix in the US while back home on vacation,
> installed it on my portable, and then lugged the portable back
> with me here to Germany...
> 

Whats with all the cross posting?  WHat a waste of bandwidth.
Was this a topic in all these groups? I have been reading them for weeks
now, and I don't remember seeing this in all three groups?

Great, well now we know that Crypt is out!  What a shock!  I hope I can
call my local secret service office before you launch all the missles
on the US of A's Trident submarines.

-- 
Adelphi University, Garden City, NY 11530                   (516) 663-1170
Department of Mathematics and Computer Science
                                 markd at adelphi.UUCP  or  mark at promark.UUCP
                      UUCP:      ...philabs!sbcs!bnlux0!adelphi!markd

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

From: Jim Frost <madd at bu-cs.bu.edu>
Subject: Re: Job Control (a la csh/ksh) from within C
Date: 11 Oct 89 19:54:34 GMT
Followup-To: comp.unix.wizards
To:       unix-wizards at sem.brl.mil

In article <20040 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
|One of the things that bothers me about many of these fancy windowing
|systems is that there is no way to dial in and use them.

See "At Home With X11/NeWS" in the June 1989 USENIX Proceedings.  One
of the things that bothers me about most windowing systems is that
they need a lot of communication between server/client, which is
painful over slow connections.  The NeWS technique is better since
many operations are local to the server and need no communication at
all.  I wouldn't have picked postscript for my language, though.

Of course you still need that bitmapped terminal at home for that, but
then again we all have one, right ;-).

jim frost
software tool & die
madd at std.com

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

From: Jim Frost <madd at bu-cs.bu.edu>
Subject: Re: UNIX history made easy
Date: 11 Oct 89 20:26:19 GMT

9 at smoke.BRL.
Followup-To: comp.unix.wizards
To:       unix-wizards at sem.brl.mil

In article <11239 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
|The point is, if you don't know who Backus, Dijkstra, Hoare, Knuth,
|Thompson, Wirth, etc. are and what their major accomplishments were,
|you shouldn't advertise yourself as a professional computer scientist.

You are mistaken.  While I admit that knowledge of what they have done
will aid you in being a computer scientist, that knowledge will not
make you one and lack of it does not necessarily degrade your ability
(although it probably will, especially for certain applications).

This is just another lesson in history: you can be more effective if
you know of the successes and failures of your predecessors, but you
can get the same job done that they did without knowledge of them --
it may just take a lot longer.  I only wish that politicians would
learn this lesson.

jim frost
software tool & die
madd at std.com

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

From: Jim Frost <madd at bu-cs.bu.edu>
Subject: Re: UNIX history made easy
Date: 11 Oct 89 21:03:43 GMT

9 at smoke.BRL.
Followup-To: comp.unix.wizards
To:       unix-wizards at sem.brl.mil

In article <17123 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F. Haugh II) writes:
|On the other hand, anyone who hasn't read ``The Mythical Man Month''
|should be fired.

Agreed.  Learn the mistakes from someone who had to make them the hard
way.

jim frost
software tool & die
madd at std.com

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

From: "Blair P. Houghton" <bph at buengc.bu.edu>
Subject: A little salve (Re: Is there an FSDB Manual?)
Date: 12 Oct 89 01:03:33 GMT
Followup-To: comp.unix.wizards
To:       unix-wizards at sem.brl.mil

In article <1288 at sdcc13.ucsd.EDU> pa1034 at sdcc13.ucsd.edu.UUCP (The Evil(tm) One) writes:

Whoever chose your name chose well...

>Any program which is publicly executable can potentially be a security
>hole.  A program can be non-SUID and still have code like:
>	{
>		exec shell to cp /bin/sh /tmp/sushi.
>		Now that the /tmp/sushi is owned by current owner,
>		  do a chmod 6777 on it.
>	}  
>Surprise! the user now has the privileges of whoever runs this program.
>if root runs it, BIG SURPRISE!!!

It can't be stopped, no.  There is a way, though, to check for the
results of such things.  (This is paraphrased from the security chapter
in Fiedler and Hunter, UNIX(tm) System Administration, Hayden,
Indianapolis, 1986.)

	find / -perm -4000 -exec ls -ldg \{\} \;

will find all files with the setuid bit set.

I do it every once in a while just to see what's up, and
it only returns a few dozen lines.  If you really want to
check, you should probably run every one of the listed
programs to make sure it's still the program it's supposed
to be.

Then again, you could just diff it with a master list you
keep locked away somewhere, then have it mail you and
pull the fire alarm if anything ever changes...

				--Blair
				  "Crank, crank, crank..."

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

From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: UNIX history made easy
Date: 12 Oct 89 02:19:28 GMT
To:       unix-wizards at sem.brl.mil

In article <8600002 at kolmogorov> ari at kolmogorov.physics.uiuc.edu writes:
>this doesn't seem to interfere with doing physics.  Oh well, 
>I guess I'm not a scientist after all.

If you had no idea who Newton, Einstein, Heisenberg, or Feynman were,
then yes I would have to say you weren't qualified as a physicist!

Remember, this thread started when somebody reported that his colleague,
who billed himself as a professional computer scientist, said that he
had no idea who Ken Thompson is or what he had done.  To me (and others)
that is comparble illiteracy to a "physicist" not knowing the names I
mentioned above.

Nobel prizes, Turing awards, etc. are of course only loosely correlated
with genuinely great names in their respective fields.

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

From: Maarten Litmaath <maart at cs.vu.nl>
Subject: timeout command in shell script!
Date: 3 Oct 89 06:00:41 GMT
To:       unix-wizards at sem.brl.mil

: This is a shar archive.  Extract with sh, not csh.
: This archive ends with exit, so do not worry about trailing junk.
: --------------------------- cut here --------------------------
PATH=/bin:/usr/bin:/usr/ucb
echo Extracting 'timeout'
sed 's/^X//' > 'timeout' << '+ END-OF-FILE ''timeout'
X#!/bin/sh
X# @(#)timeout 1.0 89/10/03 Maarten Litmaath
X
Xprog=`basename $0`
Xusage="Usage: $prog <timeout in seconds> <command>"
X
Xcase $1 in
X[0-9]*)
X	timeout=$1
X	shift
X	;;
X*)
X	echo "$usage" >&2
X	exit 2
Xesac
X
Xcase $# in
X0)
X	echo "$usage" >&2
X	exit 2
Xesac
X
Xexec 3>&2 2> /dev/null
X
Xtrap 'echo TIMEOUT >&3; exit 1' 1
Xtrap '' 14
X
Xsh -c '(sleep '$timeout'; kill -1 '$$'; kill -9 $$) & exec "$@" 2>&3' \
X	"$prog" "$@"
X
Xtrap '' 1
Xkill -14 -$$
X
Xexit 0
+ END-OF-FILE timeout
chmod 'u=rwx,g=rx,o=rx' 'timeout'
set `wc -c 'timeout'`
count=$1
case $count in
440)	:;;
*)	echo 'Bad character count in ''timeout' >&2
		echo 'Count should be 440' >&2
esac
exit 0
-- 
   Did Andy Tanenbaum get his programming   |Maarten Litmaath @ VU Amsterdam: 
instruction from a Cereal box?  (Sam McCrea)|maart at cs.vu.nl, mcvax!botter!maart

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

From: Henry Spencer <henry at utzoo.uucp>
Subject: Re: Job Control (a la csh/ksh) from within C
Date: 12 Oct 89 02:24:07 GMT
To:       unix-wizards at sem.brl.mil

In article <2491 at ibmpa.UUCP> jsalter at slo.UUCP (James Salter) writes:
>>[...] You've got other windows, remember ...
>Sure.  And on an 11" monitor, those windows will look like stamps.

Well, if you *insist* on having them all on the screen at a time, of
course they will.  Particularly on a 24x80 terminal, you wouldn't.
Call them up when you need them.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry at zoo.toronto.edu

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


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



More information about the Comp.unix.wizards mailing list