postmaster@uunet.uu.net (06/17/88)
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@arpa.brl> To: UNIX-WIZARDS@arpa.brl Reply-To: UNIX-WIZARDS@arpa.brl Subject: UNIX-WIZARDS Digest V5#069 Message-ID: <8806150245.aa21022@SEM.BRL.ARPA> Sender: unix-wizards-request@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@cgl.ucsf.edu> Subject: Re: Tool -flag considered harmful (was: grep replacement) Date: 14 Jun 88 04:38:13 GMT Sender: daemon@cgl.ucsf.edu To: unix-wizards@SEM.BRL.MIL In article <4615@vdsvax.steinmetz.ge.com> barnett@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@cgl.ucsf.edu ----------------------------- From: Francois Pinard <pinard@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@SEM.BRL.MIL In article <1988Jun7.170246.15101@utzoo.uucp>, henry@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@odyssee.uucp GNU!" (514)588-4656; Odyssee R.A.: (514)279-0716 ------------------- --------- ------------------------------------------ ----------------------------- From: "Richard A. O'Keefe" <ok@quintus.uucp> Subject: Re: grep replacement Date: 14 Jun 88 05:54:04 GMT Sender: news@quintus.uucp To: unix-wizards@SEM.BRL.MIL In article <8080@brl-smoke.ARPA> gwyn@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@hpclscu.hp.com> Subject: Re: Stupid Mistake! Date: 13 Jun 88 20:22:03 GMT To: unix-wizards@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@rain.rtech.uucp> Subject: Re: Stdio buffering question Date: 13 Jun 88 17:39:13 GMT Sender: news@rtech.uucp To: unix-wizards@SEM.BRL.MIL In article <4999@super.upenn.edu> david@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@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@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@cup.portal.com sun!portal!cup.portal.com!jeffrey_j_vanepps No cute quote since Portal doesn't have a .signature facility. ----------------------------- From: andrew@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@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@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@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@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@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@ihlpf.att.com> Subject: Re: grep replacement Date: 14 Jun 88 13:11:52 GMT To: unix-wizards@SEM.BRL.MIL In article <786@pttesac.UUCP> vanam@pttesac.UUCP (-Root Admin-) writes: >In article <4524@vdsvax.steinmetz.ge.com> barnett@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@umbc3.umd.edu> Subject: Re: yacc and lex tutorials Date: 14 Jun 88 16:02:08 GMT Keywords: yacc, lex, tutorials To: unix-wizards@SEM.BRL.MIL In article <184@asiux1.UUCP> wjm@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@umbc3.umd.edu alex@umbc3.umd.edu ----------------------------- From: Duane Morse <duane@anasaz.uucp> Subject: Shared memory info - how does one use struct shminfo? Date: 9 Jun 88 18:32:43 GMT To: unix-wizards@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@bu-cs.bu.edu> Subject: Re: Tool -flag considered harmful (was: grep replacement) Date: 14 Jun 88 16:25:57 GMT To: unix-wizards@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@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@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@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@SEM.BRL.MIL In article <2372@quacky.mips.COM> dce@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@mips.com or {ames,prls,pyramid,decwrl}!mips!dce ----------------------------- From: Paul Gluckauf Haahr <haahr@phoenix.princeton.edu> Subject: Re: Magic symlink syntax Date: 14 Jun 88 16:08:11 GMT Keywords: nami hack, namei hack To: unix-wizards@SEM.BRL.MIL In article <2371@quacky.mips.COM> dce@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@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@princeton.edu ----------------------------- From: Fai Lau <ugfailau@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@SEM.BRL.MIL In article <172@applga.UUCP> simmons@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@sunybcs INT: ugfailau@joey.cs.buffalo.EDU ----------------------------- From: Dave Decot <decot@hpisod2.hp.com> Subject: Re: POSIX Draft for UNIX Date: 14 Jun 88 09:18:18 GMT To: unix-wizards@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@gorodish.sun.com> Subject: Re: Shared memory info - how does one use struct shminfo? Date: 14 Jun 88 21:16:41 GMT Sender: news@sun.uucp To: unix-wizards@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@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@SEM.BRL.MIL In article <7942@ncoast.UUCP>, allbery@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@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl Nancy Reagan on the Mac-II architecture: "Just say Nu" ----------------------------- From: Guy Harris <guy@gorodish.sun.com> Subject: Re: Magic symlink syntax Date: 14 Jun 88 23:44:36 GMT Sender: news@sun.uucp Keywords: nami hack, namei hack To: unix-wizards@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@asiux1.uucp> Subject: Re: yacc and lex tutorial Date: 14 Jun 88 20:03:14 GMT Keywords: yacc, lex, tutorial To: unix-wizards@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@brl-smoke.arpa> Subject: Re: Tool -flag considered harmful Date: 15 Jun 88 02:37:48 GMT To: unix-wizards@SEM.BRL.MIL In article <23325@bu-cs.BU.EDU> bzs@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@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@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@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me ----------------------------- From: terryl@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@SEM.BRL.MIL In article <6926@cit-vax.Caltech.Edu> mangler@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@frip.gwd.tek.com> Subject: Of old shells and pipe symbols Date: 14 Jun 88 20:23:17 GMT Sender: andrew@tekecs.tek.com To: unix-wizards@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@relay.cs.net) [ARPA] ----------------------------- From: Doug Gwyn <gwyn@brl-smoke.arpa> Subject: Re: redirection before wildcards Date: 15 Jun 88 02:50:27 GMT To: unix-wizards@SEM.BRL.MIL In article <7979@alice.UUCP> andrew@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@brl-smoke.arpa> Subject: Re: Magic symlink syntax Date: 15 Jun 88 02:59:24 GMT To: unix-wizards@brl-sem.arpa In article <56555@sun.uucp> guy@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@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@brl-sem.arpa In article <11246@steinmetz.ge.com>, davidsen@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@spp2.uucp> Subject: 4.2bsd memall mfind crash Date: 11 Jun 88 14:34:18 GMT To: unix-wizards@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 **************************