mailer error report for <8806150245.aa21022 at SEM.BRL.ARPA>
mcvax!minster.york.ac.uk!postmaster at uunet.uu.net
mcvax!minster.york.ac.uk!postmaster at uunet.uu.net
Fri Jun 17 06:14:39 AEST 1988
Reason: local mail handler complained as follows
jmail: HuwR -- unknown user or mailbox
-------- rejected letter ---------
Via: 00004001015218/UCL-CS.FTP.MAIL ; 16 Jun 1988 04:55:37 GMT
Received: from NSS.CS.UCL.AC.UK by NSS.Cs.Ucl.AC.UK via List-Channel
id aa01720; 16 Jun 88 5:29 BST
Received: from sem.brl.mil by NSS.Cs.Ucl.AC.UK via Satnet with SMTP
id aa01705; 16 Jun 88 5:21 BST
Received: from SEM.BRL.MIL by SEM.BRL.ARPA id aa21139; 15 Jun 88 2:59 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa21022; 15 Jun 88 2:45 EDT
Date: Wed, 15 Jun 88 02:45:21 EST
From: The Moderator (Mike Muuss) <Unix-Wizards-Request at arpa.brl>
To: UNIX-WIZARDS at arpa.brl
Reply-To: UNIX-WIZARDS at arpa.brl
Subject: UNIX-WIZARDS Digest V5#069
Message-ID: <8806150245.aa21022 at SEM.BRL.ARPA>
Sender: unix-wizards-request at uk.ac.ucl.cs.nss
UNIX-WIZARDS Digest Wed, 15 Jun 1988 V5#069
Today's Topics:
Re: Tool -flag considered harmful (was: grep replacement)
Re: back to the (ivory) tower
Re: grep replacement
Re: Stupid Mistake!
Re: Stdio buffering question
Re: redirection before wildcards
Re: grep replacement
Re: redirection before wildcards
Re: Vax 11/780 performance vs Sun 4/280 performance
Re: grep replacement
Re: yacc and lex tutorials
Shared memory info - how does one use struct shminfo?
Re: Tool -flag considered harmful (was: grep replacement)
Re: Vax 11/780 performance vs Sun 4/280 performance
Re: Symlinks vs. NFS
Re: Magic symlink syntax
Re: Bug (or wierd behavior) In C Shell
Re: POSIX Draft for UNIX
Re: Shared memory info - how does one use struct shminfo?
Re: O'pain Software Foundation: (2) Why is it better than AT&T?
Re: Magic symlink syntax
Re: yacc and lex tutorial
Re: Tool -flag considered harmful
Re: Convergence of AIX and 4.3BSD
Re: Vax 11/780 performance vs Sun 4/280 performance
Of old shells and pipe symbols
Re: redirection before wildcards
Re: Magic symlink syntax
Re: Convergence of AIX and 4.3BSD
4.2bsd memall mfind crash
-----------------------------------------------------------------
From: George Seibel <seibel at cgl.ucsf.edu>
Subject: Re: Tool -flag considered harmful (was: grep replacement)
Date: 14 Jun 88 04:38:13 GMT
Sender: daemon at cgl.ucsf.edu
To: unix-wizards at SEM.BRL.MIL
In article <4615 at vdsvax.steinmetz.ge.com> barnett at steinmetz.ge.com (Bruce G. Barnett) writes:
[...]
]I am all for progress. Just remember, that there are tools used by the
]system, and tools used by humans. [...]
Well put. When programmers at AT&T are making design decisions that may
affect the way hundreds of thousands of people interact with their computers
for years to come, I wonder who checks it out? The wizard down the hall?
How many of you have ever tried to teach UNIX to a casual user? How about
trying to *sell* UNIX in industrial environments where the amount of training
required to use an O/S is a major consideration? Creeping featurism is bad,
tools are good, agreed. But there comes a time when the tool philosophy
needs to bend a little. Context in grep and diff is just such a case.
George Seibel, UCSF
seibel at cgl.ucsf.edu
-----------------------------
From: Francois Pinard <pinard at odyssee.uucp>
Subject: Re: back to the (ivory) tower
Date: 14 Jun 88 03:39:51 GMT
Posted: Mon Jun 13 23:39:51 1988
To: unix-wizards at SEM.BRL.MIL
In article <1988Jun7.170246.15101 at utzoo.uucp>, henry at utzoo.uucp (Henry Spencer) writes:
> > ... Is alloca really such a problem across differing architectures?
>
> Yes; there are architectures on which it is very difficult to implement
> efficiently. Stallman appears to have a mild case of the "all the world's
> a VAX" syndrome: he cares about portability only when it doesn't get in
> his way.
I've the feeling that you are not completely fair. Stallman made
clear choices for the GNU project, and portability in itself is not an
real issue. In the context of GNU, to "think portable" and "write
portable" may help to see and understand aspects of one given problem,
solutions that are portable may even be interesting in themselves
because they are sometimes more general and more clear. But if
portability gets in the way, it is put aside, simply.
These choices are not new, they are well documented inside the GNU
project. Stallman, to my own way of seeing things, contributed a lot
and in several ways to the programming community. Alas, I often have
the impression that a lot of people are simply standing around, crying
for "more!, more!". This is not the best way to help.
--
------------------- --------- ------------------------------------------
Francois Pinard "Vivement C.P. 886, L'Epiphanie (Qc), Canada J0K 1J0
pinard at odyssee.uucp GNU!" (514)588-4656; Odyssee R.A.: (514)279-0716
------------------- --------- ------------------------------------------
-----------------------------
From: "Richard A. O'Keefe" <ok at quintus.uucp>
Subject: Re: grep replacement
Date: 14 Jun 88 05:54:04 GMT
Sender: news at quintus.uucp
To: unix-wizards at SEM.BRL.MIL
In article <8080 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>Removing the ability to get context diffs when they are wanted WOULD
>be a bad idea. Removing this feature from "diff" itself is not a
>bad idea; I hate for "diff" to do extra work every time I run it when
>I virtually never use the context feature. Consider
> diff a b | diffc a b
>where "diffc" reads the "diff" information in parallel with the two
>files "a" and "b" to produce the context-diff output.
About half of my calls to "diff" feed it with a pipe, e.g.
NewProgramVersion <Data | diff ..Options.. - ExpectedOutput
I don't know how diff handles this, and I don't care; that's diff's job.
If you split it into two programs, someone who wants a context difference
for regression testing has to figure out how to handle pipes (him|her)self.
There is not the least fragment of a shadow of a reason for the -c option
to slow "diff" down in the cases when it is not used. As one method of
implementation, consider a stripped down diff which exec()s another program
(/lib/diffc, perhaps) when it sees the -c option.
Berkeley may have gone overboard in adding new flags, but at least adding
new flags doesn't break working code. If I have to rewrite scripts which
use only features documented in the V.2 SVID because someone decided that
his ideas of elegance were more important than my labour, I will be very
upset.
-----------------------------
From: Shankar Unni <shankar at hpclscu.hp.com>
Subject: Re: Stupid Mistake!
Date: 13 Jun 88 20:22:03 GMT
To: unix-wizards at SEM.BRL.MIL
There's always the radical solution: If you have another (like) machine around,
mount this machine's root disk as an extra file system on the other machine.
Now edit /<extrafs>/etc/passwd.
Voila!
--
Shankar
P.S. Don't forget to move the root disk back :-) :-)
-----------------------------
From: Jim Shankland <jas at rain.rtech.uucp>
Subject: Re: Stdio buffering question
Date: 13 Jun 88 17:39:13 GMT
Sender: news at rtech.uucp
To: unix-wizards at SEM.BRL.MIL
In article <4999 at super.upenn.edu> david at linc.cis.upenn.edu.UUCP (David Feldman) writes:
>When piping, stderr gets buffered so that it may be separated from stdout.
>Stdout goes through the pipe, and when it is closed, the stderr buffer gets
>flushed through the pipe. That is assuming you have redirected stderr through
>the pipe also. This is a documented feature, and I believe it is a csh thing.
>I can't remember off hand. I don't think fflush() will help, especially
>if it is done in csh. One way csh could implement this feature is to
>attach stderr to a file and then throw the file down the pipe when stdout
>closes. Any csh hackers know the details on this thing? I am guessin'.
I'll say.
Jim Shankland
..!ihnp4!cpsc6a!\
sun!rtech!jas
..!ucbvax!mtxinu!/
"The road to hell ... is where the heart is"
-----------------------------
From: Jeffrey_J_Vanepps at cup.portal.com
Subject: Re: redirection before wildcards
Date: 14 Jun 88 02:28:31 GMT
XPortal-User-Id: 1.1001.4153
To: unix-wizards at SEM.BRL.MIL
Someone asked:
"for curiosity's sake, why exactly are redirections performed
*before* wildcard expansions?"
Andrew Klossner answered:
So that, in simple-minded shells without filename completion, I can type
filter <in* | lpr
to mean
filter <in_service_report.88Apr12.version2A | lpr
I reply:
Seems to me what you have described is the desired thing to happen, but
exactly opposite of what does happen and what the first writer was curious
about. You have expansion occurring before redirection.
I've always wondered why this was this way myself. Of course, when I wrote
a shell I did it my way :-)
--
Jeffrey_J_Vanepps at cup.portal.com
sun!portal!cup.portal.com!jeffrey_j_vanepps
No cute quote since Portal doesn't have a .signature facility.
-----------------------------
From: andrew at alice.uucp
Subject: Re: grep replacement
Date: 13 Jun 88 21:50:58 GMT
Posted: Mon Jun 13 17:50:58 1988
To: unix-wizards at SEM.BRL.MIL
actually our version of the linderman sort doesn't do arbitrary-sized lines;
it does the REASONABLE thing of complaining when the lines are too long
rather than silently progressing (or looping or truncating or ...).
that is why gre will either work propoerly (handle any line length)
or settle on a (sensible) max length and complain if it gets an overflow.
-----------------------------
From: andrew at alice.uucp
Subject: Re: redirection before wildcards
Date: 13 Jun 88 21:54:57 GMT
Posted: Mon Jun 13 17:54:57 1988
To: unix-wizards at brl-sem.arpa
it is not that wildcards are expanded after redirection;
rather it is that bourne screwed the grammar. the grammar fo rthe shell
(such that it is) says essentially:
redir word
rather than
redir list
and then check that list generates just one thing. (wildcard expansion
is only done for lists.)
-----------------------------
From: dmr at alice.uucp
Subject: Re: Vax 11/780 performance vs Sun 4/280 performance
Date: 14 Jun 88 04:21:17 GMT
Posted: Tue Jun 14 00:21:17 1988
To: unix-wizards at brl-sem.arpa
After decribing a lot of the grot you have to go through to get
3MB/s out of an MVS system, Barry Shein wrote,
> But don't underestimate raw, frothing, manic hardware.
> It's a big trade-off, large IBM mainframes are to I/O what Crays are
> to floating point...
Crays are better at I/O, too. For example,
I made a 9947252-byte file by catting 4 copies of the dictionary
and read it:
3K$ time dd bs=172032 </tmp/big >/dev/null
57+1 blocks in
57+1 blocks out
seconds
elapsed 1.251356
user 0.000639
sys 0.300725
which is a cool 8MB/s read from an ordinary Unix file in competition
with other processes on the machine. (OK, I gave it a big buffer.)
The big guys would complain that they didn't get the full 10 or 12
MB/s that the disks give. They would really be annoyed that I could
get only 50 MB/s when I read the file from the SSD, which runs at
1000MB/s, but to get it to go at full speed you need to resort to
non-standard Unix things.
The disk format on Unicos (Cray's version of SVr2) is an extent-based
scheme supporting the full Unix semantics except that they don't handle
files with holes (that is, the holes get filled in). In an early
version, a naive allocation algorithm sometimes created files
ungrowable past a certain point, but I think they've worked on the
problem since then.
Dennis Ritchie
-----------------------------
From: 00704a-Lukas <lukas at ihlpf.att.com>
Subject: Re: grep replacement
Date: 14 Jun 88 13:11:52 GMT
To: unix-wizards at SEM.BRL.MIL
In article <786 at pttesac.UUCP> vanam at pttesac.UUCP (-Root Admin-) writes:
>In article <4524 at vdsvax.steinmetz.ge.com> barnett at steinmetz.ge.com (Bruce G. Barnett) writes:
>>There have been times when I wanted a grep that would print out the
>>first occurrence and then stop.
>
>sed -n -e "/<pattern>/ { p" -e q -e "}"
Can anyone explain why 3 scripts are needed? That is, why the given
script works as advertised, but neither
sed -n -e "/<pattern>/ { p q }"
or
sed -n -e "/<pattern>/ { p" -e " q }"
work (although their failure messages are slightly different)?
TIA
--
John Lukas
ihnp4!ihlpf!lukas
312-510-6290
-----------------------------
From: "Alex S. Crain" <alex at umbc3.umd.edu>
Subject: Re: yacc and lex tutorials
Date: 14 Jun 88 16:02:08 GMT
Keywords: yacc, lex, tutorials
To: unix-wizards at SEM.BRL.MIL
In article <184 at asiux1.UUCP> wjm at asiux1.UUCP (Bill Mania) writes:
>I am looking for a tutorial/textbook for yacc and for
>lex. Something similar to 'The C Programming Language'
>and 'The AWK Programming Language' would be great. I
>have had some beginning experience with lex and no
>experience with yacc and would appreciate any
>recommendations.
I learned yacc & lex from "Compiler Construction with UNIX". I
don't remember the authors, just that the book was oversize (10x14 or so)
and blue, and I have seen copies for sale in B. Daltons (mall bookstore).
The book isn't outstanding for compiler construction, but does
a fair job with PDA and reqular-expression grammer.
If you use it, watch for the typo's, there are a few.
--
:alex.
nerwin!alex at umbc3.umd.edu
alex at umbc3.umd.edu
-----------------------------
From: Duane Morse <duane at anasaz.uucp>
Subject: Shared memory info - how does one use struct shminfo?
Date: 9 Jun 88 18:32:43 GMT
To: unix-wizards at SEM.BRL.MIL
/usr/include/sys/shm.h ends with an interesting structure, shminfo,
which contains fields for various system config parameters related
to System V shared memory. I've never seen a reference to how one
should use this structure. Anybody know?
--
Duane Morse ...!noao!mcdsun!nud!anasaz!duane
(602) 861-7609
-----------------------------
From: Barry Shein <bzs at bu-cs.bu.edu>
Subject: Re: Tool -flag considered harmful (was: grep replacement)
Date: 14 Jun 88 16:25:57 GMT
To: unix-wizards at SEM.BRL.MIL
The "tool philosphy" is not at question in this grep discussion, the
question is whether grep is the right tool to provide contexts around
pattern matches rather than resorting to some other tool later just
for this special function.
I claim putting it into grep is exactly right, the "tool philosophy"
and parsimony arguments are red herrings, or reductio ad absurdum (why
have grep echo file names when it's easy enough to do in a shell
script? etc etc.)
I've yet to hear an argument here against putting the context function
into grep other than weak bleatings of parsimony.
The argument in favor is obvious, GREP HAS THE $&^%$ CONTEXT IN ITS
LITTLE HANDS, WHY LOOK FOR IT AGAIN? That is, it's just a minor
generalization of what grep does right now, grep prints the context
already, it's simply limited to one text line.
If people think that filename:linenum is so swell why not have grep
*only* produce that under all conditions? Ridiculous, right? The
whole damn argument is ridiculous.
Another anti-filename:linenum argument is what if I want to limit the
output to LESS than a single line, like printing only the exact text
matched? &c.
I may not be exactly right here, I can see complications myself, but I
think someone has to think slightly deeper than "heavens no, not
another flag to grep" as the primary basis for software design, it's
become the Mom and Apple Pie among some circles, excuses anything. It
provides a convenient bludgeon to use on the novitiate.
(tho I must agree some of these anti-tools arguments are appalling,
the groans of carpetbaggers who would prefer to see their past
failures replicated rather than learn why the system won, like the
arriviste who keep moaning that C isn't more like Fortran or PL/1, I
suspect some of them moaned about the distinct lack of manure in the
streets when autos became popularized.)
-Barry Shein, Boston University
-----------------------------
From: Barry Shein <bzs at bu-cs.bu.edu>
Subject: Re: Vax 11/780 performance vs Sun 4/280 performance
Date: 14 Jun 88 16:39:38 GMT
Posted: Tue Jun 14 12:39:38 1988
To: unix-wizards at brl-sem.arpa
Dennis Ritchie points out that his Cray observes disk I/O speeds that
compare favorably to those claimed for large IBM mainframes, thus in
contrast to my claim Crays may indeed be the "Crays" of I/O.
I think the proper question is sort/merging a disk farm and doing 1000
transactions/sec or more while keeping 8 or 12 tapes turning at or
near their rated 200 ips, not pushing bits thru a single channel (if
we're talking Crays then we're talking 3090's.)
If the Cray can keep pumping the I/O under those conditions (typical
job stream for a JC Penney's or Mastercard) then we all better short
IBM. Software or price would be no object if the Cray could do it
better (and more reliably, I guess that *is* an issue, but let's skip
that for now.)
Then again, who knows? Old beliefs die hard, far be it for me to
defend the Itsy Bitsy Machine company.
Mayhaps the Amdahl crew can provide some appropriate viciousness at
this point :-) Oh, please do!
-Barry Shein, Boston University
-----------------------------
From: David Elliott <dce at mips.com>
Subject: Re: Symlinks vs. NFS
Date: 14 Jun 88 13:57:42 GMT
Posted: Tue Jun 14 09:57:42 1988
To: unix-wizards at SEM.BRL.MIL
In article <2372 at quacky.mips.COM> dce at mips.COM (David Elliott) writes:
>We have run across a problem with NFS and symlinks that we would like
>to solve.
>
>Assume you have a remote path that is actually a symlink.
I've gotten a number of responses, and I think I need to add something.
We're trying to solve the problem for our systems as distributed,
not just our in-house systems. We can easily go through our internal
machines and fix their symlinks, but we can't assume that customers
will be using our method of organization.
So, as a first shot, I'd like to suggest that there be a modification
to symlinks that a special leading symbol mean 'root of the machine
on which this file resides'. For the sake of starting some discussion,
I'll suggest '...', though I realize that there may be conflicts.
So, if I point /usr/ucb/newaliases at '.../usr/lib/sendmail', this
would imply "go to the root of the remote machine and then go down
to usr/lib/sendmail". Obviously, this has to take into account
whether or not the final file is remotely mounted.
--
David Elliott dce at mips.com or {ames,prls,pyramid,decwrl}!mips!dce
-----------------------------
From: Paul Gluckauf Haahr <haahr at phoenix.princeton.edu>
Subject: Re: Magic symlink syntax
Date: 14 Jun 88 16:08:11 GMT
Keywords: nami hack, namei hack
To: unix-wizards at SEM.BRL.MIL
In article <2371 at quacky.mips.COM> dce at mips.COM (David Elliott) writes:
> We are in the process of considering a system modification that systems
> folks lovingly refer to as the "nami hack" (or "namei hack" for BSD folks).
> This is the modification that allows one to put a variable inside of
> a symbolic link target so that people can choose default execution
> "universes" or "modes" or "system types".
>
> I believe that the Apollo Domain/IX syntax was '($name)' or '$(name)'.
> I'd like to get a list of those currently available, as well as the
> pros and cons of each syntax.
>
> Also, if other people have come up with functionally similar systems
> that use a different mechanism, I'd like to hear about those as well.
i really don't think that this is a good idea. you suggest using
variables (presumably from the environment). pyramid (and others
following their lead, i.e. sequent) have done a "conditional symbolic
link" (like a symbolic link, maps to two (or more?) different names
depending on an entry in the proc structure or u area). both approaches
are pretty awful. i would assume you're trying to do this to provide
compatibility with different "standard" unix namespaces.
[ out of curiosity, is this to solve a problem of the past, system v
versus berkeley, or the future, at&t/sun versus osf? ]
the pyramid approach, adding a universe switch to the process state
has real problems in a networked environment, if the network protocol
does not understand the notion of conditional symlinks, which neither
NFS nor RFS do. how does a client tell a server which universe to use
for network accesses? do you break the protocol and add a universe
parameter to each NFS lookup request or adding a new incompatible
file type so that the client handles it? do you specify the universe
when you export or mount the filesystem, thereby losing the advantage
of having per-user universes in the first place.
the approach you suggest is a little better, because you don't need to
add a new file type to do it, at least with NFS, since symbolic link
interpretation is always done by the client side in NFS. however, what
if the client does not understand having a variable in a link name? for
right now, it will look up a filename that contains '$', '(', ')', or
whatever characters.
another namespace issue is: are variable evaluated in all pathnames or
just symbolic links? you can create a file with a variable name in
it, you just can't make a symlink to it?, as in (':; ' is my prompt)
:; FOO=x
:; export FOO
:; > '$(FOO)' # should this create file x?
:; ln -s '$(FOO)' y
:; > y # this should be file x
or should we go whole hog and say that it isn't symbolic links which
need to know about the environment, but all pathnames? this would
probably be easier to implement.
moreover, right now the kernel imposes almost no structure on the
environment. the NAME=VALUE usage is a user-level convention. to add
pathname variables would impose a kernel interpretation on something
that it didn't have to care about before. plus, do you really want to
search through the (possibly large) environment every time you use a
file in /usr/bin or wherever?
while it may make porting harder for some rare cases (and probably not
much even there), i would argue that sun's approach taken in SunOS 3.2
(before the controversial SysVr4 agreement on a unified unix) of
merging the universes and providing an alternate directory to put in
one's $PATH is a far better way to go than adding funny stuff to
symbolic links. (though they came up with one of the ugliest kludges
i've ever seen to handle v7 echo or system V echo as a shell builtin).
rob pike has suggested a more reasonable approach for a customizable
namespace, based on per-process (or per-process group), inherited,
non-scess group), inherited, non-superuser mount tables, that let one
graft part of a filesystem at another location. (you want system v,
sure, do a "mount /usr.systemV /usr" in your .profile). if the mount
table is inherited, my choosing one won't make the choice fover a
network, if the client can do such mounts, and it doesn't really matter
what the host does then. it just has to export a hierarchical file
system.
symbolic links are already pretty hackish. see dce at mips.com's other
current article (on symbolic links and networks) for just one reason,
and of course there is the whole debate about what .. following a
symbolic link means. the environment is pretty hackish (it's yet
another namespace, and degrades the performance of exec if it gets too
large). we're probably stuck with both of them. let's not make the
existing situation worse.
paul haahr
princeton!haahr or haahr at princeton.edu
-----------------------------
From: Fai Lau <ugfailau at sunybcs.uucp>
Subject: Re: Bug (or wierd behavior) In C Shell
Date: 14 Jun 88 21:20:27 GMT
Keywords: here script syntax oops
To: unix-wizards at SEM.BRL.MIL
In article <172 at applga.UUCP> simmons at applga.uucp (Steve Simmons) writes:
>Consider the following two scripts:
>
> OK Buggy
> #!/bin/csh | #!/bin/csh
> if ( 1 ) then | if ( 0 ) then
> cat << HERE | cat << HERE
> else | else
> HERE | HERE
> else | else
> echo There | echo There
> endif | endif
>Executing OK is fine -- it echos 'else'. Executing Buggy gives an error
> HERE: Command not found.
....
>The Bourne and Korn shell equivalents to this script work fine, ie, buggy.sh
>echos 'There'. Bug in the C shell? Or a wierdness of syntax that I can
>use to convince people Korn is better? :-)
Try
#!/bin/csh
if (0) then
cat << HETE; else; HERE
else
echo There
endif
I don't particularly like writing shell script for C shell for the
very reason that I can never tell what kind of "weirdness" would
pop up where I least expected it.
Oh, BTW, in my personal opinion, I would say that the Korn shell is
"somewhat" better than the C shell.
Fai Lau
SUNY at Buffalo (The Arctic Wonderland)
UU: ..{rutgers,ames}!sunybcs!ugfailau
BI: ugfailau at sunybcs INT: ugfailau at joey.cs.buffalo.EDU
-----------------------------
From: Dave Decot <decot at hpisod2.hp.com>
Subject: Re: POSIX Draft for UNIX
Date: 14 Jun 88 09:18:18 GMT
To: unix-wizards at brl-sem.arpa
> The POSIX draft standard can be ordered from the IEEE at:
>
> IEEE Service Center
> 445 Hoes Lane, P.O. Box 1331
> Piscataway, NJ 08855-1331
>
> It is listed as `1003.1 (Draft American National Standard) Trial-Use
> Standard Portable Operating System for Computer Environments.'
You do *NOT* want this book; it is over a year out of date. This is the
"Trial-Use" standard, not the Draft Full-Use standard that is nearing
approval.
> The standard can also be ordered from Global Engineering Documents,
> (800)854-7179.
I have no idea what this version might be.
The response from Ian Kluft gives a channel to get the correct document.
Dave Decot
hpda!decot
-----------------------------
From: Guy Harris <guy at gorodish.sun.com>
Subject: Re: Shared memory info - how does one use struct shminfo?
Date: 14 Jun 88 21:16:41 GMT
Sender: news at sun.uucp
To: unix-wizards at SEM.BRL.MIL
> /usr/include/sys/shm.h ends with an interesting structure, shminfo,
> which contains fields for various system config parameters related
> to System V shared memory. I've never seen a reference to how one
> should use this structure. Anybody know?
Yes. You refer to it by opening "/dev/kmem", finding the address of the struct
named "shminfo" by looking through your kernel's namelist, and using that
address to find the right place in "/dev/kmem" to read.
In other words, there's no system call interface that gives it to you.
-----------------------------
From: "Stephen J. Friedl" <friedl at vsi.uucp>
Subject: Re: O'pain Software Foundation: (2) Why is it better than AT&T?
Date: 13 Jun 88 15:18:49 GMT
To: unix-wizards at SEM.BRL.MIL
In article <7942 at ncoast.UUCP>, allbery at ncoast.UUCP (Brandon S. Allbery) writes:
> People, I have *yet* to meet a salesman who got technical issues right.
Q - What's the difference between a car salesman and a computer salesman?
A - A car salesman *knows* he's lying.
:-) :-) :-) :-)
:-) Steve :-)
:-) :-) :-) :-)
--
Steve Friedl V-Systems, Inc. (714) 545-6442 3B2-kind-of-guy
friedl at vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
Nancy Reagan on the Mac-II architecture: "Just say Nu"
-----------------------------
From: Guy Harris <guy at gorodish.sun.com>
Subject: Re: Magic symlink syntax
Date: 14 Jun 88 23:44:36 GMT
Sender: news at sun.uucp
Keywords: nami hack, namei hack
To: unix-wizards at SEM.BRL.MIL
> (though they came up with one of the ugliest kludges i've ever seen to
> handle v7 echo or system V echo as a shell builtin).
Blame where blame is due :-); the "look at $PATH" hack was originally conceived
by, I believe, Dave Korn (at least I got the idea from some mail I received
from dpk).
-----------------------------
From: Bill Mania <wjm at asiux1.uucp>
Subject: Re: yacc and lex tutorial
Date: 14 Jun 88 20:03:14 GMT
Keywords: yacc, lex, tutorial
To: unix-wizards at brl-sem.arpa
There has been a rather overwhelming amount of mail to
me asking the same question I asked so I will summarize
what I received.
The book that was most recommended as a yacc and lex
tutorial was:
'Introduction to Compiler Construction with Unix'
by Axel T. Schreiner and H. George Friedman, Jr.
published by Prentice-Hall with ISBN #0-13-474396-2. It
is an 8.5 x 11 194 page hardcover book. I have not had
an opportunity to read it yet but I see that it is
filled with examples and does come highly recommended.
Bill Mania, Ameritech Applied Technologies
The band is just fantastic, USENET {ihnp4,hcfeams}!asiux1!wjm
that is really what I think. VOICENET (312) 870-4574
Oh by the way which one's Pink? PAPERNET 3030 Salt Creek Lane Fl 3 Rm C6
Pink Floyd, 1975 Arlington Heights, IL 60005
-----------------------------
From: Doug Gwyn <gwyn at brl-smoke.arpa>
Subject: Re: Tool -flag considered harmful
Date: 15 Jun 88 02:37:48 GMT
To: unix-wizards at SEM.BRL.MIL
In article <23325 at bu-cs.BU.EDU> bzs at bu-cs.BU.EDU (Barry Shein) writes:
>Another anti-filename:linenum argument is what if I want to limit the
>output to LESS than a single line, like printing only the exact text
>matched? &c.
Hey, while we're at it, have an option to highlight the matched
pattern(s) in STANDOUT MODE (i.e. add control characters based on
getenv("TERM") or a -Tname option). You have to admit that would
sometimes be useful, and it depends even more than context on
what grep "has it's hands on".
How far do you want to go with this?
-----------------------------
From: "William E. Davidsen Jr" <davidsen at steinmetz.ge.com>
Subject: Re: Convergence of AIX and 4.3BSD
Date: 14 Jun 88 17:17:58 GMT
Keywords: AIX BSD 4.3
To: unix-wizards at brl-sem.arpa
I missed any reference to convergence of AIX to SVR[34]. This is
exactly what scares me about OSF is that they are going to find ways to
offer things not in SRV, and to not pick up things in SRV which benefit
the users.
My original opinion that this was a ploy to fragment UNIX to the point
that it dies still stands.
--
bill davidsen (wedu at ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------------------------
From: terryl at tekcrl.tek.com
Subject: Re: Vax 11/780 performance vs Sun 4/280 performance
Date: 14 Jun 88 16:54:29 GMT
To: unix-wizards at SEM.BRL.MIL
In article <6926 at cit-vax.Caltech.Edu> mangler at cit-vax.Caltech.Edu (Don Speck) writes:
>And as Barry Shein said, "An IBM mainframe is an awesome thing...".
>One weekend, noticing the 4341 spinning a pair of GCR drives at over
>half their rated 275 ips, I was shocked to learn that it was reading
>the disk file-by-file, not track at a time. BSD filesystems just
>can't compare to what this 2-MIPS machine could do with apparent ease.
>
>How do they get that kind of throughput? I refuse to believe that it's
>all hardware. Mainframe disks rotate at 3600 RPM like everybody else's
>and their 3 MB/s transfer rate is only slightly higher than a SuperEagle.
>A 2-MIPS CPU would be inadequate to run a BSD filesystem at those speeds,
>so obviously their software overhead is a lot lower, while at the same
>time wasting no disk time. What is VM doing efficiently that Unix does
>inefficiently?
Well, it might be partially due to hardware. Remember the dedicated
I/O channels the 360-370 systems have??? Do the 4341's have anything
similar???? Similar to CDC Cyber's peripheral(sp?) processors. Tape
drives on a Cyber are capable of blindingly fast things, but then, I've
seen a tape drive on a Cyber that could read a tape faster than ANY tape
drive could rewind under UNIX (caveat: I'm talking mainly DEC tape drives
here).
Also, reading file by file; to quote a good joke from many moons
ago: "That man must be a lawyer. The information he gave is 100% accurate,
but totally useless." We need a little (actually quite a lot) more infor-
mation before we can say anything. What's the layout of the file on the
disk??? What type of file is it??? Is it extent-based, or something
different. If it's extent-based, what are the sizes of the extents???
Is there really a file system on the disk in question, or is it just that
one file???? etc.....
Boy
Do
I
Hate
Inews
!!!!
-----------------------------
From: Andrew Klossner <andrew at frip.gwd.tek.com>
Subject: Of old shells and pipe symbols
Date: 14 Jun 88 20:23:17 GMT
Sender: andrew at tekecs.tek.com
To: unix-wizards at SEM.BRL.MIL
[]
"Before the Bourne shell there was the Mashey shell. It
supported ^ for the pipe symbol not |. This was a very
primitive shell ... For example wild card were expanded in a
separate process, yuck."
It sounds like the /bin/sh distributed with Unix v6, but that shell
accepted both '^' and '|'. In the early 1970s, terminals on which it
was easy to key '|' were not widespread. The classic terminal, the
TTY33, had no way to key '|', '{', '}', '~', or '`'. (Or lower case
letters, for that matter.)
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com at relay.cs.net) [ARPA]
-----------------------------
From: Doug Gwyn <gwyn at brl-smoke.arpa>
Subject: Re: redirection before wildcards
Date: 15 Jun 88 02:50:27 GMT
To: unix-wizards at SEM.BRL.MIL
In article <7979 at alice.UUCP> andrew at alice.UUCP writes:
> redir word
Fortunately, automatic filename completion makes this much easier to
live with. (Our shell will handle tilde expansion in "word", but
not variable substitution, which is the primary remaining gripe.)
-----------------------------
From: Doug Gwyn <gwyn at brl-smoke.arpa>
Subject: Re: Magic symlink syntax
Date: 15 Jun 88 02:59:24 GMT
To: unix-wizards at brl-sem.arpa
In article <56555 at sun.uucp> guy at gorodish.Sun.COM (Guy Harris) writes:
>> (though they came up with one of the ugliest kludges i've ever seen to
>> handle v7 echo or system V echo as a shell builtin).
>Blame where blame is due :-); the "look at $PATH" hack was originally conceived
>by, I believe, Dave Korn (at least I got the idea from some mail I received
>from dpk).
DPK or DGK?
What I have suggested is that ALL echo commands be given both -n support
(for V7/BSD compatibility) and -e support a la V8/V9. That would provide
a migration path for shell scripts and allow reasonable default behavior
for some future merged version of "echo" instead of escape mapping a la
SysV.
-----------------------------
From: Doug Gwyn <gwyn at brl-smoke.arpa>
Subject: Re: Convergence of AIX and 4.3BSD
Date: 15 Jun 88 03:08:33 GMT
Keywords: AIX BSD 4.3
To: unix-wizards at brl-sem.arpa
In article <11246 at steinmetz.ge.com>, davidsen at steinmetz.ge.com (William E. Davidsen Jr) writes:
> I missed any reference to convergence of AIX to SVR[34].
You didn't miss it; it wasn't there.
STREAMS were conspicuous by their absence, while cruft like
sockets WERE mentioned.
-----------------------------
From: Michael Urban <urban at spp2.uucp>
Subject: 4.2bsd memall mfind crash
Date: 11 Jun 88 14:34:18 GMT
To: unix-wizards at SEM.BRL.MIL
We have recently added some additional disk drives to a Vax 11/780
running 4.2bsd (yeah, I know, I know). We have since been crashing
on a "memall mfind" panic about once a day. At first I thought the
problem was that we were mounting 17 file systems with NMOUNT set to
only 15, but increasing NMOUNT to 20 failed to alleviate the problem.
I note that the clause in memall that is producing the crash is a
patch that was added (four years ago!) to alleviate another panic, the
vaguely remembered MUNHASH bug.
Does anyone know what the problem is here, and how to fix it? This is
starting to cost us big bucks.
--
Mike Urban
...!trwrb!trwspp!spp2!urban
"You're in a maze of twisty UUCP connections, all alike"
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list