Unix-Wizards-Request@arpa.brl (Mike Muuss) (06/23/88)
UNIX-WIZARDS Digest Thu, 23 Jun 1988 V5#077 Today's Topics: Re: new grep Re: UNIX-WIZARDS Digest V5#066 sh(1) command substitution and here documents Re: new grep Re: I'm going to hate myself Re: back to the (ivory) tower Re: I'm going to hate myself Re: sh(1) command substitution and here documents Re: Spooling to an Encore annex via lpd Re: determine the current directory of a son-process (longish) Re: ksh weird files Re: Stdio (stderr) buffering question Re: sh(1) command substitution and here documents Re: Tool -flag considered harmful Re: How good is Apollo UNIX? (was: O'pain Software Foundation: (2)) Re: Spooling to an Encore annex via lpd implementing pseudo-asynchronous io on SYS5 Re: sh(1) command substitution and here documents Re: Curses & Color Re: UNIX-WIZARDS Digest cmp efficiency Re: Stdio (stderr) buffering question ----------------------------------------------------------------- From: Mohamed Ellozy <mohamed@hscfvax.harvard.edu> Subject: Re: new grep Date: 21 Jun 88 12:20:18 GMT Posted: Tue Jun 21 08:20:18 1988 To: unix-wizards@SEM.BRL.MIL In article <16237@brl-adm.ARPA> williams@nrl-css.arpa writes: > Al Aho and I are designing a replacement for grep, egrep > and fgrep. The question is what flags should it support and > what kind of patterns ... > > I have always thought it would be nice to print only the first match. > > (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> > >I'll second this. There have been many times when I simply wanted to >detect the presence of a pattern in a file, then stop searching. Combining >this with the -n option can also be useful. Also times when I am searching for something that is close to the start of a long file (e. g. a host that is close to the start of /etc/hosts). I can save time by doing a head -NNN | grep, but I must guess a suitable value for NNN, while a grep that quits after the first match does it for me. ----------------------------- From: Stephen Samuel <rroot@edm.uucp> Subject: Re: UNIX-WIZARDS Digest V5#066 Date: 21 Jun 88 23:52:44 GMT To: unix-wizards@SEM.BRL.MIL From article <8806120245.aa01039@SEM.BRL.ARPA>, by Unix-Wizards-Request@arpa.brl (Mike Muuss): >> ... This is not an attempt to pick on Henry Spencer... > Who, me, criticize Berkeley? Nah. :-) .... > useful changes; Berkeley's problem is an excess of enthusiasm for new > and nifty ideas, without adequate consideration of whether they are > *good* ideas. This enthusiasm is no problem -- indeed, it's desirable -- > in a research lab that produces papers instead of software. But when the > end product is software that thousands of sites end up depending on, one > could wish for a bit more restraint. Yeah, but they WERE a research lab that produced papers. I have this funny feeling that, when they started out, they weren't expecting the number of people that ended up using BSD to do so.. It's kinda like FORTRAN: You can't really blame them for the wonderful leap that they made possible, but you can sure as shootin' scream bloody murder about all the stumbles that came after the leap. The only reason we're here, complaining abbout 4.X now, is that it was good enough that it's progeny are proliferating about the whole UNIX world (both the good and the bad, but the bad are SLOOOL...Y being stomped out). We can't throw out the baby with the bathwater, but I agree that we shouldn't keep the bathwater just because the baby's in it. -- ------------- Stephen Samuel {ihnp4,ubc-vision,vax135}!alberta!edm!steve or userzxcv@uofamts.bitnet ----------------------------- From: Jack Nelson <jack@cadre.dsl.pittsburgh.edu> Subject: sh(1) command substitution and here documents Date: 19 Jun 88 19:48:20 GMT To: unix-wizards@SEM.BRL.MIL The following shell script prints out 0.75 on a line and ends, which seems to follow the sh(1) manual. #!/bin/sh bc <<End scale = 2 3 / 4 End What I would like to do is incorporate this calculation result into a shell variable using the here document: #!/bin/sh var=`bc <<End scale=2 3 / 4 End ` But this doesn't work; an error message "cannot open /tmp/sh01383" always is produced, both on 4.3 and 2.10 systems. Is there a way to do this? Can one deduce this behavior from the manual? I ended up using a one-line perl script; I suppose awk would work just as well. Expr(1) won't do floats. -- John P. Nelson, M.D., 3811 O'Hara St, Pittsburgh, PA 15213, t:412-624-1769 Dept. of Psychiatry, U. of Pittsburgh UUCP: { akgua | allegra | cmcl2 | idis | ihnp4 | mi-cec | pitt | psuvax1 | sun | sunrise | vax135 } ! cadre ! jack ARPA: jack@cadre.dsl.pittsburgh.edu ----------------------------- From: "XMRP50000[jcm]-a.v.reed" <avr@mtgzz.att.com> Subject: Re: new grep Date: 21 Jun 88 18:29:38 GMT To: unix-wizards@SEM.BRL.MIL In article <16237@brl-adm.ARPA>, williams@nrl-css.arpa writes: < Al Aho and I are designing a replacement for grep, egrep < and fgrep. The question is what flags should it support and < what kind of patterns ... < < I have always thought it would be nice to print only the first match. < (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> < I'll second this. There have been many times when I simply wanted to < detect the presence of a pattern in a file, then stop searching. Combining < this with the -n option can also be useful. This would be a good time to make the flags orthogonal and consistent. Ideally, all standard output should be requested in the same way, by specifying the corresponding flag. The default should be something like the -s option today; the way to specify one's own favorite options would be by defining an alias, e.g. mygrep="grep -i -l -n -m" The options I'd like to see are: -l List paths (names) of files with matches -n Number: list numbers of lines that match -b Block: list block number for each match -m Matching lines: list matching lines -c Display a count of maching lines in each file -o One: Don't search beyond one match per file plus the -v, -i, -e, and -f options as they are now. Ideally, there should be a new name; if the new tool is called with one of the names that exist today, then the behavior of the old tool of that name ought to be emulated exactly. Adam Reed (mtgzz!avr) ----------------------------- From: uhclem@trsvax.uucp Subject: Re: I'm going to hate myself Date: 20 Jun 88 14:42:00 GMT Nf-ID: #R:beta.lanl.gov:20355:trsvax:193500005:000:1619 Nf-From: trsvax.UUCP!uhclem Jun 20 09:42:00 1988 To: unix-wizards@SEM.BRL.MIL <> B>1. What ever happened to Digital Systems House? Dunno. B>2. If they are gone (likely), who inherited the trademark for B> MINIX(tm)? According to a letter I got in the US MAIL on Friday, offering to sell me MINIX, MINIX(TM) is a registered trademark of Prentice Hall, Inc. B>3. What happens to a trademark (such as MINIX(tm)) when a company B> goes away?? Trademarks die hard. When companies are bought out, they usually transfer to the new owner. If the company goes under, the creditors can sell it just like any other asset, as long as it is still in force. FYI, The MINIX software is available for $79.95 for these targets: A. 640K IBM PC (full binaries and sources) #58387-2 B. 256K [ha!] IBM PC (same as above, except no C compiler is present [double ha!] #58388-0 C. 512K IBM AT (full binaries and sources) #58386-4 D. 9-track industry standard magnetic tape for class use on a VAX #58389-8 They are also pushing a book called "Design of the UNIX operating system" by Maurice J. Bach, for $37.33. And another book "Operating Systems Design and Implementation" #63740-5 for $39.33. The business reply address is PRENTICE-HALL, Inc. Book Distribution Center Route 59 at Brook Hill Drive West Nyack, New York, 10995 <I'm not a lawyer, but I sound like one, and I would like to tell you about some wonderful tree-covered acreage I have available near Odessa Texas....> "Thank you, Uh Clem." Frank Durda IV @ <trsvax!uhclem> ...decvax!microsoft!trsvax!uhclem ...convex!infoswx!hal6000!trsvax!uhclem ...sys1!hal6000!trsvax!uhclem ----------------------------- From: der Mouse <mouse@mcgill-vision.uucp> Subject: Re: back to the (ivory) tower Date: 22 Jun 88 14:09:31 GMT Posted: Wed Jun 22 10:09:31 1988 To: unix-wizards@SEM.BRL.MIL In article <500@philmds.UUCP>, leo@philmds.UUCP (Leo de Wit) writes: > But I have a nice alternative: lets always use alloca() and a new > function, call it freea(), in pairs. > For [compilers] that don't [support alloca]: > #define alloca malloc /* the oldies */ > #define freea free Then why bother with alloca, if the semantics are such that malloc can be used instead? > Everybody happy? No. The people who use alloca to get automatic freeing on a longjmp (or other stack unwind) won't be able to tolerate the malloc replacement. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu ----------------------------- From: Andy Tanenbaum <ast@cs.vu.nl> Subject: Re: I'm going to hate myself Date: 21 Jun 88 21:43:46 GMT Keywords: Trademarks To: unix-wizards@brl-sem.arpa In article <20347@beta.lanl.gov> hwe@beta.lanl.gov (Skip Egdorf) writes: >MINIX is a trademark of Digital Systems House Interesting, interesting. Here comes one of those stories that only insiders know. The derivation of UNIX is as follows. Ken Thompson was one of the programmers on MULTICS, the MULTIplexed Information and Computing Service projected started by MIT, Bell Labs and GE. After Bell Labs pulled out, Ken found an unused PDP-7 and tried writing MULTICS on his one. Brian Kernighan noted that it only supported 1 user, so it should be called Unics (Uni being the Latin for 1). The spelling got garbled later. My original name for this system was MONICS (the MONoplexed Information and Computing Service, Mono being Greek for 1). The spelling later got garbled to MONIX. All my students knew it under this name. Then Prentice-Hall did a trademark search and discovered that MONIX was the trademark of some French company. Bye MONIX. I then suggested MINIX, STUNIX, and various other names. Then did trademark searches on them and MINIX was not anybody's trademark, so we picked it. I can't explain the Digital Systems House alleged trademark except to say they must not have done a very good job of trademarking it since it didn't show up in a very specific search for it. Andy Tanenbaum (ast@cs.vu.nl) -- Andy Tanenbaum (ast@cs.vu.nl) ----------------------------- From: WU SHI-KUEI <wu@spot.colorado.edu> Subject: Re: sh(1) command substitution and here documents Date: 22 Jun 88 15:06:19 GMT Sender: news@sigi.colorado.edu To: unix-wizards@brl-sem.arpa In article <1254@cadre.dsl.PITTSBURGH.EDU> jack@cadre.dsl.pittsburgh.edu.UUCP (Jack Nelson) writes: > . . . an explanation of what he wants to do >What I would like to do is incorporate this calculation result into a shell >variable using the here document: > #!/bin/sh > var=`bc <<End > scale=2 > 3 / 4 > End > ` > . . . error messages, why doen't it work etc. You don't need or want the here document. The following will do just fine: #!/bin/sh # not needed with REAL UNIX var=`bc ' scale = 2 3 / 4 quit'` The 'quit' is essential since bc keeps reading the standard input after the command have been read. Carl Brandauer ihnp4!nbires!bdaemon!carl 303-442-1731 ----------------------------- From: John Sloan <jsloan@wright.edu> Subject: Re: Spooling to an Encore annex via lpd Date: 22 Jun 88 11:19:25 GMT To: unix-wizards@SEM.BRL.MIL in article <10657@ames.arc.nasa.gov>, medin@cincsac.arc.nasa.gov (Milo S. Medin) says: > Don't worry about pscomm. R4.0 has a feature where you can run a > reverse telnet daemon that creates a file that pscomm can open and read > and write, etc... The daemon then does a TCP connect to the annex > port of your choosing. A really nice idea. > > Fixed in 4.0! > > Milo R4.0 of what? SunOS? Annex software from Encore? Transcript? I embarressed to admit that shortly after I made my prior posting about not being able to spool to a LaserWriter via an Annex serial port, it occurred to me how in fact it might be done using a pty/tty pair. Dumb dumb dumb. I'm debugging now. If/when it works as well as I think it should, I'll ship the filter off to Rich Salz for comp.unix.sources, unless is obsolesced by something else sooner. -- John Sloan, The SPOTS Group Wright State University Research Building CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!wright!jsloan +1-513-259-1384 +1-513-873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail. ----------------------------- From: Wayne Mesard <mesard@bbn.com> Subject: Re: determine the current directory of a son-process (longish) Date: 22 Jun 88 15:46:05 GMT Sender: news@bbn.com Followup-To: comp.unix.wizards To: unix-wizards@brl-sem.arpa [ N.B. followups to wizards.] From article <579@gmdzi.UUCP>, by valder@gmdzi.UUCP (Wilhelm Valder): > Does anyone know how to determine the current working directory (CWD) of > a son-process in UNIX. Any hints, comments, solutions are appreciated. > > The problem: In our current implementation of a command listener, we > have one process that builds up a command line and sends it to a son > process (normally /bin/sh or /bin/sh) that has been forked and exec'd > during startup. The two processes communicate via pseudo ttys (pty's). Geez, why don't you hack the shell source? Well, none of my business I suppose. Anyway, I was in the same situation when I was writing a UNIX [BSD] tutorial last summer on CMU's Andrew system. I had the tutorial running in one window, and a shell in another. The tutorial had to listen to what the user typed and provid helpful information. The communication worked almost like yours except I had a third program involved. What I did was this: o At startup, the tutorial opens a pipe stream to a "voyeur" program which acts as an intermediary between the shell and the tutorial, and between the user and the shell. Before making the call, the tutorial ensures that its stderr goes to the same place as its stdout (see below) (via dup(2)). o The voyeur then sets up a pty and forks a shell which it could talk and listen to via the pty. ------------ ------------ ------------ | | pipe | | pty | | | Tutorial |<======= | Voyeur | <========> | Shell | | | (V's | | (Shell's | | ------------ stdout) ------------ stdout,in ------------ ^ | & err) stdin | | stderr | V So, in voyeur's main loop: o It does a select to wait for input from the keyboard (the user) or from the pty (the shell). o On shell output, voyeur first sends a copy to its stderr (which is the screen) so that the user can see it (no flames, please). Remember, that the shell is only talking to the pty and voyeur's stdout goes to the tutorial. Next it sends a copy to the tutorial (via it's stdout) along with some control messages to advise the tutorial of where the incoming data came from. o On stdin (keyboard) input it sends a copy down the stdout to both the shell and the tutorial. Now to get to your question: On keyboard input, it checks to see if the typed string is a request for change of directory and if it is, voyeur (1) asks the shell for the new directory name (2) warns the tutorial that important data is on the way and to wait for it: if (!strncmp(buf, "cd", 2) || !strncmp(buf, "chdir", 5) || !strncmp(buf, "pushdir", 7) || !strncmp(buf, "popdir", 6)) { (void) write(ptyfd, "echo \007\007$cwd\001\n", 13); (void) write(1, "\001\001WAIT\n", 7); } Meanwhile, there is a check in voyeur's shell output handler to watch for messages with double Ctrl-G's. It knows that this is the answer to its question, finds the useful information and sends it as a control message to the tutorial. if (sel & (1 << ptyfd)) { /* output from shell */ int n = read (ptyfd, buf, BUFSIZ); [...] if ((newdir = index(buf, '\007')) && *(newdir+1) == '\007') { (void) write(1, "\001\001CWD:",6); (void) write(1, newdir+2, (int)(index(buf, '\001') - newdir - 2)); (void) write(1, "\n", 1); (void) write(2, buf, (int)(newdir - buf)); /* If we didn't get the prompt after $cwd, get it next time. */ okay_to_write = n - (int)(index(newdir,'\n')-buf) - 1; *newdir = '\0'; } else if (okay_to_write) (void) write(2, buf, n); else okay_to_write = 1; } } I wasn't sure whether or not to include the "okay_to_write" nonsense in this article, but since I have, I might as well, explain it: The user should have no idea that we're sneaking that echo command to his/her shell. So of course we don't echo the output. But we also have to make sure that the prompt which gets printed after the "echo" command is also suppressed. Since this stuff comes down the pty asynchronously, it might get read in one packet ("^G^G/usr/newdir^A\nprompt>") which is no problem, or in two packets ("^G^G/usr/newdir^A\n", "prompt>") in which case we have to wait for and suppress the second one. Now, I realize that this routine can be easily defeated, and lose big in some cases, but the general algorithm is a sound and efficient way to preprocess input to and output from a command processor. -- unsigned *Wayne_Mesard(); MESARD@BBN.COM BBN Labs, Cambridge, MA Is it because of the people you hang around with that you say you do not need dan rather? M-x psychoanalyze-pinhead (Gee, whataneditor!!) ----------------------------- From: der Mouse <mouse@mcgill-vision.uucp> Subject: Re: ksh weird files Date: 22 Jun 88 17:36:41 GMT Keywords: ksh shell scripts, not weird Posted: Wed Jun 22 13:36:41 1988 To: unix-wizards@SEM.BRL.MIL In article <1289@ark.cs.vu.nl>, maart@cs.vu.nl (Maarten Litmaath) writes: > In article <494@philmds.UUCP> leo@philmds.UUCP (L.J.M. de Wit) writes: >> When login or getty or whoever goes to exec the sh script, how does >> it know which command interpreter to use (I don't think it knows of >> #! lines, in fact it doesn't even know the c.i. issue) ? > The magic number #! is well-known to the KERNEL! This is system-dependent. BSD kernels (recent ones, at least) do indeed handle #! on their own; I understand that SV kernels generally do not. (I don't know about any others, eg V7/V8/V9, SIII, etc.) >> And another question: how do you display text with >> echo << END-OF-TEXT >> text here >> END-OF-TEXT As you probably discovered, you don't: you use cat instead of echo. Using echo here makes about as much sense as saying cat textfile | echo der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu ----------------------------- From: der Mouse <mouse@mcgill-vision.uucp> Subject: Re: Stdio (stderr) buffering question Date: 22 Jun 88 17:44:23 GMT Posted: Wed Jun 22 13:44:23 1988 To: unix-wizards@brl-sem.arpa In article <5027@sdcsvax.UCSD.EDU>, hutch@net1.ucsd.edu (Jim Hutchison) writes: > So how many things break if stderr is line buffered? (Meaning that > when you get a \n or a full buffer WECF.) Very little will actually break, but it will make stderr next to useless for debugging. It would force the poor programmer to follow ever fprintf(stderr,...) with fflush(stderr) to make up for it - why uglify everyone's code for no good reason? The efficiency argument is quite bogus (for stderr). Stderr is used for two things: printing error messages (efficiency irrelevant, buffering probably acceptable) and printing debugging messages (efficiency irrelevant, buffering definitely harmful). There are exceptions to this general rule (tar cvf - being notable), but they are few enough that inserting a setbuf or setlinebuf call is no great pain. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu ----------------------------- From: Hitoshi Aida <aida@porthos.csl.sri.com> Subject: Re: sh(1) command substitution and here documents Date: 22 Jun 88 18:18:58 GMT Sender: usenet@csl.csl.sri.com To: unix-wizards@brl-sem.arpa In article <6774@sigi.Colorado.EDU> wu@spot.Colorado.EDU (WU SHI-KUEI) writes: >The following will do just fine: > > #!/bin/sh # not needed with REAL UNIX > var=`bc ' > scale = 2 > 3 / 4 > quit'` Not quite correct. The following will do just fine: #!/bin/sh # not needed with REAL UNIX var=`echo ' scale = 2 3 / 4 quit' | bc` "quit" can be omitted. Hitoshi AIDA (aida@csl.sri.com) Computer Science Lab, SRI International ----------------------------- From: der Mouse <mouse@mcgill-vision.uucp> Subject: Re: Tool -flag considered harmful Date: 22 Jun 88 18:07:31 GMT Posted: Wed Jun 22 14:07:31 1988 To: unix-wizards@brl-sem.arpa In article <8090@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > 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). To take this in an entirely different way from what you intended.... I have a program which is like cat except that certain strings (specified on the command line) get replaced with underscore-backspace-character sequences. If the standard output is a tty, it automagically pipes its output through ul to make it come out in the appropriate standout mode for the terminal. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu ----------------------------- From: "Kenneth T. Smelcer" <kts@quintro.uucp> Subject: Re: How good is Apollo UNIX? (was: O'pain Software Foundation: (2)) Date: 14 Jun 88 06:37:31 GMT To: unix-wizards@SEM.BRL.MIL In article <697@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: >Ron Natalie @ Rutgers notes: >> The Apollo systems I've been forced to use do such a poor imitation >> of UNIX that I have no wonder that you have problems with SVVS. > >A friend of mine who uses Apollo says the same thing as well. > > >In Apollo's defense, Nathanial Mishkin (mishkin@apollo.uucp) says: >> In at least some ways, SVVS as it is currently constituted >> thus stifles innovation. I think stifling innovation is something >> none of us want. > >Isn't it *wonderful* how people can make sunshine out of sh*t? :-) > This isn't the place for a "How good is Apollo Unix" war, but I just had to put my $0.02 in defense of Domain/IX. Despite their reputation, Apollo has been doing a fairly good job in the past few years of integrating Unix into their environment. The older Apollo releases (pre-9.0) had real problems, but the current release (9.7) is quite Unix compatible (for both SysVR2 and BSD 4.2). I have very few problems with programs from comp.sources.* (most run without any modifications), and I think they've done a decent job integrating SysV, BSD, and Aegis into a usable, coherent package. I don't know about IBM and DEC, but Apollo has definitely demonstrated their commitment to Unix, and to the unification of the various flavors of Unix into a common platform. As far as the SVVS is concerned, I'd be interested in hearing any details about the problems Domain/OS (also known as SR10) had passing the verification suite. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corporation - Quincy, Il. UUCP: att-ih!spl1!quintro!kts or {att-ih,uunet}!wucs1!wuibc!quintro!kts ----------------------------- From: "Milo S. Medin" <medin@cincsac.arc.nasa.gov> Subject: Re: Spooling to an Encore annex via lpd Date: 22 Jun 88 23:47:03 GMT Sender: usenet@ames.arc.nasa.gov To: unix-wizards@SEM.BRL.MIL R4.0 of the Annex software. It's in beta test now, and hopefully will be out soon. You get the source for a program called rtelnet on the tape. Works great. Kudo's to Encore for 'doing the right thing'. I only wish all our vendors did... Thanks, Milo ----------------------------- From: Evan Wallace <wallace@cme-durer.arpa> Subject: implementing pseudo-asynchronous io on SYS5 Date: 22 Jun 88 16:09:40 GMT Keywords: OSI To: unix-wizards@brl-sem.arpa We think it desirable to build a standard interface to OSI services for our applications. The operating systems these applications will operating on are Sun OS V3.X, SYS5 (Microport 386) and VMS. The applications in question are actually high level services which include communication and thus the peice of the applications doing communications will be required to manage multiple transports (channels). While I can see how this could be supported in an inelegant way with sockets and select(2) call on the Sun (which could be simulated on the VAX, I can't find any way to support a multi-channeled asynchronous service on SYS5. I would appreciate info on how others have (would or will) solved this problem on SYS5. Thanks, Evan Wallace Arpanet address: wallace@durer.cme.nbs.gov ----------------------------- From: "William E. Davidsen Jr" <davidsen@steinmetz.ge.com> Subject: Re: sh(1) command substitution and here documents Date: 22 Jun 88 17:27:23 GMT To: unix-wizards@brl-sem.arpa In article <1254@cadre.dsl.PITTSBURGH.EDU> jack@cadre.dsl.pittsburgh.edu.UUCP (Jack Nelson) writes: | What I would like to do is incorporate this calculation result into a shell | variable using the here document: | #!/bin/sh | var=`bc <<End | scale=2 | 3 / 4 | End | ` | But this doesn't work; an error message "cannot open /tmp/sh01383" | always is produced, both on 4.3 and 2.10 systems. Is there a way | to do this? Can one deduce this behavior from the manual? This was fixed after V7. It works in SysIII sh, SysV sh, ksh, and sh on Sun (which is mostly sysV I believe). It fails on V7 and every BSD version I could try. Since Berkeley hasn't fixed it (and some similar problems) perhaps you can get ksh. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me ----------------------------- From: Larry Williamson <larry@focsys.uucp> Subject: Re: Curses & Color Date: 20 Jun 88 13:51:24 GMT To: unix-wizards@SEM.BRL.MIL In article <43200020@uicsrd.csrd.uiuc.edu> davej@uicsrd.csrd.uiuc.edu writes: > > I need to do colors with curses. ... I was looking for this same feature about a month ago. It turns out that system V Release 3 is supposed to support colour. I don't know first hand if this is true as I don't have a copy of Release 3 yet. larry -- Larry Williamson Focus Automation Systems UUCP: watmath!focsys!larry 608 Weber St. N, Waterloo, Ontario N2V 1K4 +1 519 746 4918 ----------------------------- From: Mike Adams <mdadams@surya.waterloo.edu> Subject: Re: UNIX-WIZARDS Digest Date: 21 Jun 88 11:00:35 GMT Sender: daemon@watale.waterloo.edu To: unix-wizards@brl-sem.arpa In article <16229@brl-adm.ARPA> I wrote: >Would you please add the following address to the UNIX-WIZARDS Digest >subscription list: > unix-wizards@surya.uwaterloo.ca Please don't. Sorry for the confusion. Mike ----------------------------- From: Nick Crossley <nick@ccicpg.uucp> Subject: cmp efficiency Date: 23 Jun 88 01:08:21 GMT To: unix-wizards@brl-sem.arpa > While we're on the subject of efficiency, cmp is coded wrong. It should > first stat the two files to be compared. If the character count is different, > so are the files. And files tend to be different more often than the same. First, files given to cmp are quite likely to be the same, in my experience. Second, if the files are not the same size, cmp will tell you if they have the same contents up to the length of the shorter (cmp will say 'EOF on file 1/2'). I find this useful in some contexts, and would not want cmp just to give up if the sizes differed. -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick ----------------------------- From: Dave Jones <djones@megatest.uucp> Subject: Re: Stdio (stderr) buffering question Date: 23 Jun 88 03:38:48 GMT To: unix-wizards@SEM.BRL.MIL I'll play Devil's advocate for a bit, while I'm waiting for a phone call. From article <1178@mcgill-vision.UUCP), by mouse@mcgill-vision.UUCP (der Mouse): In article <5027@sdcsvax.UCSD.EDU), hutch@net1.ucsd.edu (Jim Hutchison) writes: >> So how many things break if stderr is line buffered? (Meaning that >>when you get a \n or a full buffer WECF.) > Very little will actually break, but it will make stderr next to > useless for debugging. It would force the poor programmer to follow > ever fprintf(stderr,...) with fflush(stderr) to make up for it - why > uglify everyone's code for no good reason? Just end the fprintf's with \n. That's what I do. (We have Sun3, which has line-buffered stderr.) Not too ughly. > The efficiency argument is quite bogus (for stderr). Stderr is used > for two things: printing error messages (efficiency irrelevant, > buffering probably acceptable) and printing debugging messages > (efficiency irrelevant, buffering definitely harmful). I once worked with a computer (now defunct) which had one master cpu and several slave cpu's -- the slaves were device controllers. stderr was character-buffered, and each character required locking the system bus, an interrupt to the master cpu, and a system call on the master. When things were going badly, these one-character interruptions could bring the system to its knees. Admittedly an unusual case. > There are > exceptions to this general rule (tar cvf - being notable), but they are > few enough that inserting a setbuf or setlinebuf call is no great pain. > No pain if you have the source code handy, and permission to change /bin, and willingness to do it on every new release. later, Dave J. ----------------------------- End of UNIX-WIZARDS Digest **************************