From rc-owner Sun Dec 29 05:02:22 1991 Received: from po3.andrew.cmu.edu ([128.2.12.31]) by archone.tamu.edu with SMTP id <18892>; Sun, 29 Dec 1991 04:55:11 -0600 Received: by po3.andrew.cmu.edu (5.54/3.15) id for rc@archone.tamu.edu; Sun, 29 Dec 91 05:55:02 EST Received: via switchmail; Sun, 29 Dec 1991 05:55:01 -0500 (EST) Received: from mycroft.bh.andrew.cmu.edu via qmail ID ; Sun, 29 Dec 1991 05:53:53 -0500 (EST) Date: Sun, 29 Dec 1991 04:53:48 -0600 From: "Julian L. Ho" Subject: builtin exit To: rc@archone.tamu.edu Message-Id: <694002955.8576.0@mycroft.bh.andrew.cmu.edu> It would be nice if exit took strings like 'sigint', etc... just a single string (a list like return handles wouldn't be possible, I know). It would also be nice if signal handlers had some way of telling how they were called (I'm thinking setting $status on entry to signal handlers, or possibly $*, to some meaningful string). For example, I'd like something like this to work: pipes=() fn sigexit sigint sigquit { s=$status { rm $pipes exit $s } } #code that builds $pipes (list of files) and does things with #it The idea is to have the script exit with 'sigint', 'sigquit', the argument to builtin exit (if its used), or the exit status of the last command (if we just fall off the end in "code...")... Currently, I'm doing something like: pipes=() fn sigint sighup sigquit { rm $pipes exit 1 } #code... # Normal exit follows (a copy of the cleanup code in the handler) rm $pipes But that only works because my code doesn't call builtin exit in the middle... also, exiting with the exit status of the cleanup code (rm in this example) isn't necessarily correct. If the user causes an interrupt, the cleanup actions are taken but the exit status is 1, not 'sigint', or whatever... From rc-owner Sun Dec 29 07:50:44 1991 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <18900>; Sun, 29 Dec 1991 07:45:04 -0600 Received: by doolittle.vetsci.su.oz.au id <49431>; Mon, 30 Dec 1991 00:44:12 +1100 From: John (I've got some bad news for you, sunshine) Mackin Date: Sun, 29 Dec 1991 06:45:53 -0600 To: The rc Get-Someone-Else-To-Do-The-Work List Subject: Re: builtin exit In-Reply-To: <694002955.8576.0@mycroft.bh.andrew.cmu.edu> Message-ID: <199112292345.23238.rc.babum@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ No changes to rc are needed to do any of this. As to getting the exit status right, the way we've been doing it for years in sh is still perfectly adequate; adapted for rc, it's like this: estat = 0 fn sigexit { # place any cleanup actions here builtin exit $estat } fn exit { if ( ! ~ $#* 0 ) { estat = $1 } else estat = 0 builtin exit # in order to get sigexit invoked } This works just fine for, on the one hand, making sure that cleanup happens, and, on the other, making sure that if the script says "exit ", then "something" is indeed its exit status (which is, of course, the problem with straightforward use of sigexit). Most scripts don't need this trick, but it's an easy one when it is needed. It doesn't require bending the body of the script in any way, except that if you are weird enough to want the exit status to indeed be that of the last synchronously executed command, rather than zero, if you `fall out the end', then you need to add "exit $status" to the end of the script. I can't think of many applications where this is necessary or desirable. And if you have truly been taking VERY strange substances, and believe that it actually matters that the script exits with a SIGINT even though the interrupt you sent it was handled by the script, well you can do that too. Do the above, encapsulating the cleanup actions in a function called "cleanup". Then: sigs = (int quit hup) # the signals we're weird enough to want # to do this with for (s in $sigs) { eval fn sig ^ $s '{' \ cleanup ';' \ fn sig ^ $s ';' \ kill - ^ ` { tr a-z A-Z <<< $s } $pid \ '}' } Caveats: (1) SysVile versions of tr will need square brackets; (2) some systems still probably have versions of kill(1) that insist on signal numbers instead of names, but that's just a matter of detail. I've tested this and it works, under rc 1.2; things may well change with the release of 1.3, which will have completely reworked signal handling. Because of 1.2's special handling of sigint (which, I might add, is 100% justified from my point of view), the code above doesn't actually give sigint back to the parent; it works fine for the other signals, though. To conclude, I'd just like to state my main points again: firstly, most scripts don't need the elaborate exit status handling I presented initially. For the occasional one that does, it's easy. Secondly, I don't think ANY script needs the bizarre signal status handling that was proposed. But, finally, if you do happen to need it -- it's _there already_, thanks to the clean design of rc; no more `features' are needed for any of this. While the exit status handling was just as easy in sh, the mere thought of trying to get the quoting right to handle the signal status -- if it could be done at all -- fills me with eldritch horror. _Clean design pays ongoing dividends._ OK, John. From rc-owner Wed Jan 1 07:37:12 1992 Received: from charon.cwi.nl ([192.16.184.142]) by archone.tamu.edu with SMTP id <18897>; Wed, 1 Jan 1992 07:34:34 -0600 Received: by charon.cwi.nl with SMTP; Wed, 1 Jan 1992 14:34:10 +0100 Received: by paling.cwi.nl via EUnet; Wed, 1 Jan 1992 13:34:09 GMT Date: Wed, 1 Jan 1992 07:34:09 -0600 From: Robert.van.Liere@cwi.nl Message-Id: <9201011334.AA24838@paling.cwi.nl> To: rc@archone.tamu.edu Subject: call unix I'm probably missing something that is quite obvious but does anyone out there use call unix ('cu') to transfer files to/from home ? Call unix reads data from standerd input and, except for lines starting with ~ (thats right, the tilde !), passes it to the remote system. Lines starting with a tilde has special meanings. Unfortunately, rc doesn't like this at all and (rightly so) complains about syntax errors, etc, etc .. Is there something I can do so that I can run cu with rc ? (what I do now is first go into /bin/sh before invoking cu). -- Robert PS : I *have* to use cu because slip is just to slow (no ISDN (yet) here in Amsterdam). Robert van Liere, Department of Interactive Systems, Center for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands email: robertl@cwi.nl | tel: +31-20-592-4053 | fax: +31-20-592-4199 From rc-owner Fri Jan 10 15:26:25 1992 Received: from po5.andrew.cmu.edu ([128.2.10.105]) by archone.tamu.edu with SMTP id <18890>; Fri, 10 Jan 1992 15:18:14 -0600 Received: by po5.andrew.cmu.edu (5.54/3.15) id for rc@archone.tamu.edu; Fri, 10 Jan 92 15:46:35 EST Received: via switchmail; Fri, 10 Jan 1992 15:46:34 -0500 (EST) Received: from sherlock.bh.andrew.cmu.edu via qmail ID ; Fri, 10 Jan 1992 15:46:04 -0500 (EST) Date: Fri, 10 Jan 1992 14:45:58 -0600 From: "Julian L. Ho" Subject: file globbing on command names To: rc@archone.tamu.edu Message-Id: <695075883.4747.0@sherlock.bh.andrew.cmu.edu> (from the rc man page: PATTERN MATCHING There are two forms of pattern matching in rc. One is traditional shell globbing. This occurs in matching for file names in argument lists: command argument argument ... When the characters *, [ or ? occur in an argument, rc looks at the argument as a pattern for matching against files. ) rc 1.2 seems to glob commands as well as arguments. either it or the man page needs changed... the man page seems to say that if I have an executable at the front of my path named 'echo?', i can type: echo? foo bar to run it... but this isn't so if there is a file named 'echox' in the current directory... rc behaves as if I had typed 'echox foo bar'. -J From rc-owner Sun Jan 12 15:13:57 1992 Received: from nac.no ([129.240.2.40]) by archone.tamu.edu with SMTP id <18927>; Sun, 12 Jan 1992 15:07:07 -0600 Received: by nac.no (5.64+IDA/Babel-1.6/6.0) id AAnac03733; Sun, 12 Jan 1992 22:06:07 +0100 Received: by bibsyst.no (/\==/\ Smail3.1.21.1 #21.19) id ; Sun, 12 Jan 92 20:12 GMT Message-Id: From: tore@bibsyst.no (Tore Morkemo) Subject: background processes To: rc@archone.tamu.edu (rc list) Date: Sun, 12 Jan 1992 14:12:16 -0600 X-Mailer: ELM [version 2.3 PL11] Hi ! If I start a backgroud process in rc, it seems to loose it's information about the controlling tty. The result of this is that the background process doesn't appear when I do a simple ps command, since ps by default shows processes associated with the current terminal. I'm kinda used to doing a ps to check whether my make's have finished yet. Now I have to do ps -u .... It's not a big problem but is this a bug or was it made like this ? Why ? I've compiled rc with NOEXECVE and EXECVE=execve.o, and running SCO (I know....don't blame me) Tore. +----------------------------------------------------------------------+ ! Tore Morkemo, Bibliotek-Systemer A/S, N-3250 Larvik, Norway ! ! uucp: ...!bibsyst.no!tore Tel: +47 34 82 202 ! ! tore@bibsyst.no Fax: +47 34 85 185 ! +----------------------------------------------------------------------+ From rc-owner Sat Jan 18 17:16:02 1992 Received: from eros.uknet.ac.uk ([192.91.199.2]) by archone.tamu.edu with SMTP id <18941>; Sat, 18 Jan 1992 17:10:30 -0600 Received: from ibmpcug.co.uk by eros.uknet.ac.uk with UUCP id <8053-0@eros.uknet.ac.uk>; Sat, 18 Jan 1992 12:43:24 +0000 Received: by ibmpcug.Co.Uk (smail2.5) id AA12584; 17 Jan 92 15:10:42 GMT (Fri) X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: rc@archone.tamu.edu Subject: ile Message-Id: <9201171510.AA12579@ibmpcug.Co.Uk> Date: Fri, 17 Jan 1992 09:10:40 -0600 From: Matthew Farwell Just to save me doing it, has anyone ported it to Sys 5/Xenix? Dylan. -- Opinions above are mine, unless discovered to be wrong. From rc-owner Mon Jan 20 11:34:23 1992 Received: from nac.no ([129.240.2.40]) by archone.tamu.edu with SMTP id <18932>; Mon, 20 Jan 1992 11:19:22 -0600 Received: by nac.no (5.64+IDA/Babel-1.6/6.0) id AAnac17130; Mon, 20 Jan 1992 17:29:34 +0100 Received: by bibsyst.no (/\==/\ Smail3.1.21.1 #21.19) id ; Sun, 19 Jan 92 20:01 GMT Message-Id: From: tore@bibsyst.no (Tore Morkemo) Subject: history on SCO To: rc@archone.tamu.edu (rc list) Date: Sun, 19 Jan 1992 14:01:27 -0600 X-Mailer: ELM [version 2.3 PL11] -- Hi ! Due to a "bug" in SCO's cc compiler the history program won't work. It seems that constants declared in an enumeration is limited to short. Since a short is only 2 bytes the enum chunk with CHUNKSIZE = 65536 will end up defining CHUNKSIZE as 0 ! I solved this by changing CHUNKSIZE to a #define CHUNKSIZE 65536 since the enum chunk is never being used by history.c Tore. +----------------------------------------------------------------------+ ! Tore Morkemo, Bibliotek-Systemer A/S, N-3250 Larvik, Norway ! ! uucp: ...!bibsyst.no!tore Tel: +47 34 82 202 ! ! tore@bibsyst.no Fax: +47 34 85 185 ! +----------------------------------------------------------------------+ From rc-owner Fri Jan 24 13:20:44 1992 Received: from pineapple.bbn.com ([128.11.0.16]) by archone.tamu.edu with SMTP id <18894>; Fri, 24 Jan 1992 12:57:20 -0600 Received: from LITCHI.BBN.COM by pineapple.bbn.com id ; Fri, 24 Jan 92 13:56:52 -0500 From: Rich Salz Received: by litchi.bbn.com id ; Fri, 24 Jan 92 13:56:48 EST Date: Fri, 24 Jan 1992 12:56:48 -0600 Message-Id: <9201241856.AA29699@litchi.bbn.com> To: rc@archone.tamu.edu Subject: Revised version of ile I ran ile through lint, Saber, indent, "cat -s" :-), and fixed up a few other things -- it now uses getopt, has only a single exec() call, no more [fp]printf, etc. I also cleaned up the manpage. I've been in touch with the author, and for now I'm just going to make it known to the RC users here. The shar file is 59K; a compressed version is on ~/incoming on archone.tamu.edu at 26K. ! ftp && echo 'Email me for a copy' :-) For those who don't know, ile is a program that opens a pty and spawns a child, providing command-line editing for any process run underneath it. It's very nice. /r$ From rc-owner Fri Jan 24 13:53:18 1992 Received: from pineapple.bbn.com ([128.11.0.16]) by archone.tamu.edu with SMTP id <18889>; Fri, 24 Jan 1992 13:36:48 -0600 Received: from LITCHI.BBN.COM by pineapple.bbn.com id ; Fri, 24 Jan 92 14:35:48 -0500 From: Rich Salz Received: by litchi.bbn.com id ; Fri, 24 Jan 92 14:35:42 EST Date: Fri, 24 Jan 1992 13:35:42 -0600 Message-Id: <9201241935.AA00124@litchi.bbn.com> To: rc@archone.tamu.edu Subject: Re: Revised version of ile Oh yeah -- if anyone comes up with vi-compatible bindings, then we can do vile rc From rc-owner Wed Jan 29 06:19:27 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <18905>; Wed, 29 Jan 1992 06:15:16 -0600 Received: by doolittle.vetsci.su.oz.au id <49168>; Wed, 29 Jan 1992 23:14:43 +1100 From: John (I've got some bad news for you, sunshine) Mackin Date: Wed, 29 Jan 1992 06:08:59 -0600 To: Byron Rakitzis cc: The rc Mailing List Subject: really bad order of evaluation bug Message-ID: <199201291936.423.rc.badas@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Byron, I got your mail this morning but haven't had time to reply today, and I have to get off and sleep soon. But before I do I thought I had better mail you this one. I spent four hours tracking this down today -- sigh. I thought I should copy it to the list since it's so very drastic. The symptom here was that on one particular type of machine -- Sony News, but the 68000 one, not the MIPS one -- redirection wasn't working right. If you did ls thisisntthere >xxxx >[2=1] then the error message -- which was most definitely getting printed on fd 2 -- came out _on the terminal_, and xxxx ended up with nothing in it. This didn't happen on any other machine I had easy access to. Actually, having found it, I'm really surprised that it isn't broken in more places: perhaps it is and people just haven't noticed. This is an order of evaluation bug in glom.c, which was introduced between 0.9 and 1.0 -- 1.0 has new code here and it has been broken ever since. Here is the fix: *** glom.c-BUG Wed Jan 29 18:42:34 1992 --- glom.c Wed Jan 29 18:41:48 1992 *************** *** 516,522 **** } words = words->u[0].p; } ! return append(append(glom(words), last), glom(n->u[1].p)); case BACKQ: return backq(n->u[0].p,n->u[1].p); case CONCAT: --- 516,523 ---- } words = words->u[0].p; } ! first = append(glom(words), last); ! return append(first, glom(n->u[1].p)); case BACKQ: return backq(n->u[0].p,n->u[1].p); case CONCAT: I guess that either damn near every compiler out there evaluates function arguments left-to-right (where _are_ the pcc-based ones any more? :), or else the people who use right-to-left compilers don't use `fancy' redirections.... I'll reply to your other mail tomorrow my time. Say 10-12 hours. OK, John. From rc-owner Fri Jan 31 08:35:30 1992 Received: from pineapple ([128.11.0.16]) by archone.tamu.edu with SMTP id <18888>; Fri, 31 Jan 1992 08:31:17 -0600 Received: from litchi.bbn.com by pineapple id ; Fri, 31 Jan 92 09:30:59 -0500 From: Rich Salz Received: by litchi.bbn.com id ; Fri, 31 Jan 92 09:30:55 EST Date: Fri, 31 Jan 1992 08:30:55 -0600 Message-Id: <9201311430.AA16141@litchi.bbn.com> To: rc@archone.tamu.edu Subject: Bug in my ile revision A couple of folks have pointed out that I didn't initialize the "initfile" variable in main(). Oops. Add "initfile=NULL;" before the getopt call. I put a new version on archone. /r$ From rc-owner Fri Jan 31 15:16:45 1992 Received: from relay1.UU.NET ([137.39.1.5]) by archone.tamu.edu with SMTP id <18921>; Fri, 31 Jan 1992 15:12:54 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04225; Fri, 31 Jan 92 16:12:37 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 161111.10046; Fri, 31 Jan 1992 16:11:11 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa28925; Fri, 31 Jan 92 16:01:14 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@archone.tamu.edu Subject: Match operator puzzlement Date: Fri, 31 Jan 1992 15:01:15 -0600 Message-Id: <9201311601.aa02527@ceres.srg.af.mil> Reply-To: srg!culliton@uunet.uu.net OK maybe it's just 'cuz it's Friday but my poor brain refuses to come up with a good answer to this one. While writing some fairly large and complex rc scripts I had a requirement to match something against a list of patterns specified at the command line and figured it'd be easy give rc's ~ match operator. The first attempt was something like this: patterns=`{echo $1} # go from '*.o *.a' to (*.o *.a) # lots of stuffto generate a list on file names.... for (i in $list) { if (~ $i $patterns) { dealwith $i } else { handle $i } } Which didn't work as planned for semi-obvious reasons involving re-scanning. This didn't distress me too much because I mostly understood why after a bit of thought. The next most obvious thing to try was somthing like this patterns=$1 # we don't care if it's a list for this # lots of stuff to generate a list on file names.... for (i in $list) { if (eval ~ $i $patterns) { # etc... OOPS! I encountered a file name with a $ in it so make that if (eval ~ '$i' $patterns) { # etc... But what about patterns with $ and so forth in them? If we make $patterns a list again and say '$patterns' to protect against that, we get literal matching. I haven't been able to find a way out of the swamp here any words of wisdom would be appreciated. Thanks for listening. Tom From rc-owner Sat Feb 1 11:29:30 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <18887>; Sat, 1 Feb 1992 11:26:17 -0600 Received: by doolittle.vetsci.su.oz.au via suspension id <49380>; Sun, 2 Feb 1992 04:25:30 +1100 Received: by doolittle.vetsci.su.oz.au id <49379>; Sun, 2 Feb 1992 03:36:31 +1100 From: John (I've got some bad news for you, sunshine) Mackin Date: Sat, 1 Feb 1992 10:02:08 -0600 To: The rc Mailing List cc: Tom Culliton Subject: Re: Match operator puzzlement In-Reply-To: <9201311601.aa02527@ceres.srg.af.mil> Message-ID: <199202020302.19891.rc.badey@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Tom Culliton raised some interesting points about pattern matching. Which didn't work as planned for semi-obvious reasons involving re-scanning. The reason a straightforward attempt doesn't work isn't really anything to do with rescanning at all, since there IS no rescanning -- don't forget that that is rc's main principle: in the absence of 'eval', which exists to break the rule, there is NEVER rescanning. The reason it doesn't work is, to quote Byron, for metacharacters in a ~ pattern to behave as metacharacters, they must appear _literally_ and _unquoted_. Nothing else will serve; no subterfuge, however subtle, will make them match unless they are literal and not quoted. Usually this doesn't present a problem, since a simple eval suffices. Tom, however, has either a weird application (if this really is a practical problem) or a curious bent of mind (if it's just a theoretical one), since he posits: OOPS! I encountered a file name with a $ in it so make that if (eval ~ '$i' $patterns) { # etc... But what about patterns with $ and so forth in them? Hmm. Filenames with $ in them? I didn't know rc had been ported to VMS :). Seriously, filenames with $ in them are not a good idea. Still, the above does deal with that. As to patterns with $ in them, that's what makes this an interesting question. In fact, let's leave eval aside for a moment, and consider just the question of how to match a pattern with $ in it. Now, ~ 'get$down' 'get$down' does work, naturally, and as naturally, ~ 'get$down' get$down does not, since the $down in the pattern is variable-expanded (into nothing since I don't have that set). Everything you would expect to work, does work. All these match: ~ 'get$down' *n ~ 'get$down' *down ~ 'get$down' get?down And this doesn't: ~ 'get$down' '*$down' Recall the basic principle: the metacharacter must be literal and unquoted to be effective. So leaving eval aside, we have to ask this question: how can the metacharacter be unquoted, to be effective, and the $ be quoted, to prevent variable expansion? When we know the question, the answer is obvious: ~ 'get$down' * ^ '$down' which does indeed match as expected. The answer to Tom's question is simply to use the same mechanism along with eval, using the exact code of his last example: patterns = $1 ... if ( eval ~ '$i' $patterns ) The point, though, is that if the pattern is to contain any of rc's syntax characters, appropriate quoting must be used. $ is not the only character that causes these problems; consider a pattern containing '=' -- similar hassles arise there. So one cannot just write cmd '*.o *.a *$bar' but must rather write cmd '*.o *.a * ^ ''$bar''' I am willing to admit that this is a touch cumbersome. However, in closing I'd like to stick up for the way rc works here. It is simple and clean and _predictable_, unlike other shells. I'd hate to even imagine trying something like this in csh. And I'd like to just beat a little harder on an earlier point: UNIX gives us a hell of a lot of power in many ways. Not the least of those is our ability to put any character in a pathname segment other than NUL or slash. But, as always, the converse of power is responsibility; being a properly responsible UNIX citizen means being aware that if we are going to put characters in pathnames that don't, by all rights, reasonably belong there (like $), we have to accept the consequences (our tools get harder to create, and have more work to do). Of course, the beauty of UNIX is that as long as we _are_ willing to accept the consequences, we _can_ do it. And the beauty of rc is that it's easy to see how. OK, John. From rc-owner Sat Feb 1 11:51:55 1992 Received: by archone.tamu.edu id <18888>; Sat, 1 Feb 1992 11:49:11 -0600 From: Byron Rakitzis To: rc Subject: Re: Match operator puzzlement Message-Id: <92Feb1.114911cst.18888@archone.tamu.edu> Date: Sat, 1 Feb 1992 11:49:02 -0600 Hm. I think I can do a little better than John here. The two following sed substitutions should be ok to quote all characters in a word except the metacharacters *, ? and [. The sed scripts will FAIL if there are single quotes in the input, but I'm sure there's a way around that problem too, I just haven't thought of a good way yet. Anyway: First you turn all single non-meta characters into quoted characters: sed 's/\([^[*?]\)/''\1''/g' # using rc's quoting rules, of course. e.g., "Hello?" goes to "'H''e''l''l''o'?" Now you need to remove all '' sequences: sed 's/''''//g' Now "Hello?" becomes "'Hello'?", which is exactly what we want. Not bad. (BTW, I think I can prove by induction that this method works for all strings which do not contain a ', but I do not have enough room to write the proof here :-) So the ~ example becomes something like: eval ~ 'subject' `{echo $funky_pattern | sed garbage} From rc-owner Sat Feb 1 12:38:10 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <18890>; Sat, 1 Feb 1992 12:35:40 -0600 Received: by doolittle.vetsci.su.oz.au id <49379>; Sun, 2 Feb 1992 05:35:07 +1100 From: John (I've got some bad news for you, sunshine) Mackin Date: Sat, 1 Feb 1992 12:02:44 -0600 To: The rc Mailing List Subject: Re: Match operator puzzlement In-Reply-To: <92Feb1.114911cst.18888@archone.tamu.edu> Message-ID: <199202020502.20639.rc.badig@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Byron gives us: sed -e 's/\([^[*?]\)/''\1''/g' -e 's/''''//g' Damn good thinking. Top notch in fact. It is possible to make this work for input containing ', but in an indirect manner. I think you have to be indirect since I don't think a grep-style RE can do that. In practice, there is a neat enough solution: assume that newline doesn't appear in the input string and initially map ' into newline, then map that back into '' on output. As long as the character you pick doesn't occur in the input it's fine. Yes, it's a kludge, but I would be very surprised to find people with real applications for command-line patterns containing newline. I'm not prepared to say that it can't be done with an egrep-style (full) RE but I can't see a solution. If anyone has one please mail it to the list. Extending Byron's sed produces this (with $nl being a newline, as usual): sed -e 's/''/\' ^ $nl ^ '/g' \ -e 's/\([^[*?]\)/''\1''/g' \ -e 's/''''//g' \ -e 's/\n/''''/g' OK, John. From rc-owner Sat Feb 1 12:45:29 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <18919>; Sat, 1 Feb 1992 12:43:50 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA15213; Sat, 1 Feb 92 19:43:35 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA22370; Sat, 1 Feb 92 19:43:33 +0100 Date: Sat, 1 Feb 1992 12:43:33 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202011843.AA22370@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: Re: Match operator puzzlement Could someone please give a more elaborated example? I'm afraid I don't see the point here. Malte. From rc-owner Sat Feb 1 13:48:48 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <18920>; Sat, 1 Feb 1992 13:46:39 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA15333; Sat, 1 Feb 92 20:46:26 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA22543; Sat, 1 Feb 92 20:46:25 +0100 Date: Sat, 1 Feb 1992 13:46:25 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202011946.AA22543@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: Re: Match operator puzzlement It seems to me that weird problems deserve weird solutions. I'd suggest to try selfmodifying rc-code, something like prog = `function_generating_rc_script eval $prog Malte. From rc-owner Sun Feb 2 18:33:52 1992 Received: by archone.tamu.edu id <45329>; Sun, 2 Feb 1992 18:30:02 -0600 From: Byron Rakitzis To: rc Subject: rc tweak Message-Id: <92Feb2.183002cst.45329@archone.tamu.edu> Date: Sun, 2 Feb 1992 18:30:00 -0600 I am making a tweak to rc: if rc is invoked with any of the three usual file descriptors (0, 1, 2) closed, rc will open /dev/null on that descriptor. I'm just checking to see that I'm not making a big gaffe here---I want to avoid the nastiness that arises when Unix utilities are called with any of those 3 descriptors closed. (also knowing that 0, 1, 2 are always valid fd's simplifies the bookkeeping inside rc, but that is of secondary importance) From rc-owner Mon Feb 3 08:54:25 1992 Received: from relay2.UU.NET ([137.39.1.7]) by archone.tamu.edu with SMTP id <45329>; Mon, 3 Feb 1992 08:49:41 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA03740; Mon, 3 Feb 92 09:49:27 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 094521.239; Mon, 3 Feb 1992 09:45:21 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa13484; Mon, 3 Feb 92 9:22:06 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@archone.tamu.edu Subject: Re: Match operator puzzlement Date: Sun, 2 Feb 1992 14:20:38 -0600 Message-Id: <9202021520.aa00569@ceres.srg.af.mil> Reply-To: srg!culliton@uunet.uu.net John Mackin writes: > The reason a straightforward attempt doesn't work isn't really anything > to do with rescanning at all, since there IS no rescanning I thought about adding "or lack thereof", honest I did! But since it seemed to imply that not rescanning was wrong it got left out. The real difficulty, which I saw quite clearly, is that ~ doesn't accept a list of patterns (primarily so you can match the empty list) so the eval is needed to flatten the command out and rescan it (flattening the list doesn't work because it becomes a single item) but at this point we get undesired rescanning (in a filename context?) which is not easily quoted away. There also seems to be a minor ambiguity between string matching contexts and filename expansion contexts. In most contexts $ gives the contents of variable (or something related) and patterns (using * ? []) give a list of filenames. In matching contexts $ works the same but patterns are compared against strings. Where the two collide it gets a bit messy. Given: patterns=('*.o' '*.a') # or patterns='*.o *.a' eval ~ '$i' $patterns It's not clear to me which context *.o will be evaluated in. Will it filename expand to a whole list of patterns which are then matched? This matters for obvious reasons. Maybe Byron can clarify this? For the curious the application is to scan a development directory tree automatically generating a makefile/target for configuration management purposes. One of the requirements was to be able to exclude files matching a certain template or set of templates (given on the command line) from the target, typically things like *.o *.a and other generated or binary files. While testing it I actually did encounter a filename with a $ in it (a backup or temporary file for some app) 8-P and while I don't like names like that, my program can't just choke on them! My less than satisfactory solution was to carefully document that the patterns had to be quoted, just so, when they are given on the command line. Byron's sed script seems like it will solve most of the problem and John's newline hack should cover any remaining glitches. Tom From rc-owner Mon Feb 3 11:12:35 1992 Received: by archone.tamu.edu id <45330>; Mon, 3 Feb 1992 11:09:19 -0600 From: Byron Rakitzis To: rc Subject: Re: Match operator puzzlement Message-Id: <92Feb3.110919cst.45330@archone.tamu.edu> Date: Mon, 3 Feb 1992 11:09:06 -0600 Re: evaluating *'s. The rule is simple. Globbing happens after nearly everything else, so if you have a command that begins with a ~, the ~ will "steal" the metacharacters: foo='*' eval ~ bar $foo gets rescanned as ~ bar * which returns true. From rc-owner Thu Feb 6 16:39:13 1992 Received: by archone.tamu.edu id <45332>; Thu, 6 Feb 1992 16:24:04 -0600 From: Byron Rakitzis To: rc Subject: Announcing rc-1.3beta Message-Id: <92Feb6.162404cst.45332@archone.tamu.edu> Date: Thu, 6 Feb 1992 16:24:01 -0600 This is to announce the availability of rc-1.3beta. I don't expect many problems with this shell, but just in case I would like readers of this list to have a first crack at using this shell before it is released to the public at large. Even though the number of bug fixes between 1.2 and 1.3 are not astronomical, the code has undergone considerable change (in part because I work more and more from a 2400 baud connection, so things are more bunched up now :-) The CHANGES file is included at the end of this note. Also some of the changes which fix one bug, e.g., poor handling of signals, in fact required quite a lot of work. Included with rc this time is a readline-compatible (called "editline") package written by Simmy Turner (simmy@capitol.com). Please refer any problems with it to him, not to me, at least for the duration of this beta test. I will try to get a good version from Simmy by the time rc-1.3 is out, but I don't really have anything to do with his code. Anyway, that aside, it should be noted that Simmy's package weighs in at about 1/10th the size of GNU readline!! On my NeXT, it fit in under a page of text, so happened that rc-1.3 with and without the new editing code had the same text and data sizes! (Though I think it's fair to say that GNU's code is probably more feature- laden.) Well, enough talk. Enjoy. Byron. (As usual, mail-only people mail me for a copy, or use ftpcmd) ====== Changes since 1.2: (Too many to count!) A memory stomping bug was fixed (provoked by assigning a variable to its old value plus something else). Better signal handling; a real signal handler which manages a queue of pending signals was added. rc now ignores SIGQUIT and traps SIGINT even in non-interactive mode. Thus, rc ed.sh will not do mysterious things if the shell script "ed.sh" calls a command like "ed" and then you hit ^C. rc now opens 0, 1, 2 on /dev/null if they are inherited closed. rc -o prevents this. A couple of stupid O(n^2) string appends were replaced with O(n) loops. This should make foo=`{cat /etc/termcap} bar=$^foo a little faster :-) Returning a list of signals from a function is now legal, so "return $status" should always work. The code has been revised, new printing routines have been added. rc no longer uses redundant braces when exporting functions. A first stab at a verification suite has been added (trip.rc). (someone, please help me make this comprehensive!) rc -p now does not initialize functions from the environment. This should make it easier to write shell scripts that don't need to assume anything about the environment. Inherited ignored signals are now ignored in the current shell and passed on ignored to the child processes. whatis -s also reflects this information. A file descriptor leak in the /dev/fd implementation of >{} was fixed. A variable set to '' was not imported from the environment; this has been fixed. From rc-owner Fri Feb 7 07:43:04 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45332>; Fri, 7 Feb 1992 07:40:05 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA21539; Fri, 7 Feb 92 14:39:49 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA11380; Fri, 7 Feb 92 14:39:47 +0100 Date: Fri, 7 Feb 1992 07:39:47 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202071339.AA11380@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: first impressions rc 1.3beta I just ftp'ed rc-1.3beta. It seems to be quite good work and it does deal correctly with trip.rc. Configurations for which this is tested: sparc 1,1+,2,ELC SunOS 4.1.1 gcc 1.40 sun 3/80 SunOS 4.1.1 gcc 1.40 DecStation 5000 Ultrix 4.1 gcc 1.40 IBM RS6000 AIX 3.1.5 native cc Congratulations! Something I just want to mention: In the Makefile it reads "Use bison if you will, but yacc generates a smaller y.tab.c, ..." which is not true, at least for bison 1.16, the current version. Also in Makefile, target clean does not remove sigmsgs.c. Trip.rc does rely on the existance of /etc/termcap which not true on AIX machines. _______________________________________________________________________________ malte@techfak.uni-bielefeld.de send mail reply to: Universitaet Bielefeld, Technische Fakultaet z. Hd. Malte Uhl Postfach 8640 4800 Bielefeld 1 From rc-owner Fri Feb 7 07:59:04 1992 Received: from charon.cwi.nl ([192.16.184.142]) by archone.tamu.edu with SMTP id <45333>; Fri, 7 Feb 1992 07:53:59 -0600 Received: by charon.cwi.nl with SMTP; Fri, 7 Feb 1992 14:53:39 +0100 Received: by paling.cwi.nl with SMTP; Fri, 7 Feb 1992 13:53:38 GMT Message-Id: <9202071353.AA10065@paling.cwi.nl> To: malte@techfak.uni-bielefeld.de Cc: rc@archone.tamu.edu Subject: Re: first impressions rc 1.3beta In-Reply-To: Your message of "Fri, 07 Feb 1992 07:39:47 MET." <9202071339.AA11380@dahlie.techfak.uni-bielefeld.de> From: Robert van Liere X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands X-Phone: tel: +31-20-592-4053 | fax: +31-20-592-4199 Date: Fri, 7 Feb 1992 07:53:37 -0600 Sender: Robert.van.Liere@cwi.nl In message <9202071339.AA11380@dahlie.techfak.uni-bielefeld.de> you write: > >Configurations for which this is tested: >sparc 1,1+,2,ELC SunOS 4.1.1 gcc 1.40 >sun 3/80 SunOS 4.1.1 gcc 1.40 >DecStation 5000 Ultrix 4.1 gcc 1.40 >IBM RS6000 AIX 3.1.5 native cc > rc-1.3beta also works as advertised on more orthodox architectures such as : SGI 4D/35, Indigo Irix 4.0.1 native cc IBM PC/RT AOS 4.3 gcc 1.39 -- Robert From rc-owner Fri Feb 7 09:07:38 1992 Received: by archone.tamu.edu id <45332>; Fri, 7 Feb 1992 08:57:28 -0600 From: Byron Rakitzis To: rc Subject: Re: first impressions rc 1.3beta Message-Id: <92Feb7.085728cst.45332@archone.tamu.edu> Date: Fri, 7 Feb 1992 08:57:21 -0600 Re: bison. bison generates a larger file than old Berkeley yacc, my reference point. Now, this is starting to look like useless information, since no one seems to be running the old yacc! (NeXT does---I'll keep using it as long as I can for ALL my rc builds). I'll take the comment out. Re: trip.rc and /etc/termcap. It needs a big file. What's a big file that can be found on System V as well as Berkeley systems? (A big TEXT file, not /*unix). And note that "passing trip.rc" does not really mean much at this point--- as a verification suite it is hopelessly inadequate. I just wanted to push one out the door so people could see that I do intend to eventually follow this route. Byron. From rc-owner Fri Feb 7 14:27:15 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45332>; Fri, 7 Feb 1992 14:21:50 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2609>; Fri, 7 Feb 1992 15:21:15 -0500 To: rc@archone.tamu.edu Subject: Re: first impressions rc 1.3beta In-reply-to: Your message of "Fri, 07 Feb 92 08:53:37 EST." <9202071353.AA10065@paling.cwi.nl> Date: Fri, 7 Feb 1992 14:21:10 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Feb7.152115est.2609@groucho.cs.psu.edu> I just tried out the new line editing code bundled with 1.3. Here's a quibble: On SunOS, if you don't use the streams ioctls (and do use the bsd ones) you lose typeahead whenever you switch modes. I prefer typeahead. From rc-owner Fri Feb 7 14:31:22 1992 Received: from ashley.cs.widener.edu ([147.31.254.132]) by archone.tamu.edu with SMTP id <45333>; Fri, 7 Feb 1992 14:27:18 -0600 Received: by ashley.cs.widener.edu id AA21539 (5.65c/Widener-4.1); Fri, 7 Feb 1992 15:23:08 -0500 Date: Fri, 7 Feb 1992 14:23:08 -0600 From: Brendan Kehoe Message-Id: <199202072023.AA21539@ashley.cs.widener.edu> To: byron@archone.tamu.edu Cc: rc@archone.tamu.edu In-Reply-To: Byron Rakitzis's message of Fri, 7 Feb 1992 08:57:21 -0600 <92Feb7.085728cst.45332@archone.tamu.edu> Subject: first impressions rc 1.3beta Reply-To: brendan@cs.widener.edu From: Byron Rakitzis Date: Fri, 7 Feb 1992 08:57:21 -0600 Re: bison. bison generates a larger file than old Berkeley yacc, my reference point. Now, this is starting to look like useless information, since no one seems to be running the old yacc! (NeXT does---I'll keep using it as long as I can for ALL my rc builds). I'll take the comment out. Since you bring it up (and I figure a bunch of people reading this right now have a good amount of experience with 'em--more than I, at least), I'm going to take a quick liberty... I'm putting together a reference card (same format as the GNU emacs refcard) for Bison & Flex; if any of you have suggestions on what information would be really good to have on such a thing, I'd love to hear them. We return you to your regularly scheduled beta test. This message will self-destruct in ten seconds. -- Brendan Kehoe, Sun Network Manager brendan@cs.widener.edu Widener University Chester, PA This is the .signature that Bell Atlantic doesn't want you to see. From rc-owner Fri Feb 7 20:36:39 1992 Received: by archone.tamu.edu id <45329>; Fri, 7 Feb 1992 20:34:32 -0600 From: Byron Rakitzis To: rc Subject: big files Message-Id: <92Feb7.203432cst.45329@archone.tamu.edu> Date: Fri, 7 Feb 1992 20:34:29 -0600 David Sanderson came up with a really neat idea for generating a large file: use od on the rc that trip.rc has in its path; od $rc | sed 5000q > $bigfile I liked it so much I thought I'd bring it to general attention. From rc-owner Sat Feb 8 05:03:55 1992 Received: from munnari.oz.au ([128.250.1.21]) by archone.tamu.edu with SMTP id <45329>; Sat, 8 Feb 1992 05:02:19 -0600 Received: from cerberus.bhpese.oz (via metro) by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA02039; Sat, 8 Feb 1992 22:01:59 +1100 (from Sm@cerberus.bhpese.oz.au) Received: from localhost by cerberus.bhpese.oz.au with ELM 2.3 PL5 id AA05781; Sat, 8 Feb 1992 22:01:08 +1100; sendmail 5.65c/Sm3.0RMSU (from Sm@cerberus.bhpese.oz.au for rc@archone.tamu.edu@munnari.oz.au) Message-Id: <199202081101.AA05781@cerberus.bhpese.oz.au> From: Scott Merrilees Subject: path caching To: rc@archone.tamu.edu (The rc Mailing List) Date: Sat, 8 Feb 1992 16:01:07 -0600 X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9["; Sat, 8 Feb 1992 07:32:09 -0600 From: dws@cs.wisc.edu (DaviD W. Sanderson) Message-Id: <9202081331.AA07997@skinner.cs.wisc.edu> Received: by skinner.cs.wisc.edu; Sat, 8 Feb 92 07:31:51 -0600 Subject: Re: path caching To: rc@archone.tamu.edu Date: Sat, 8 Feb 1992 07:31:50 -0600 X-Mailer: ELM [version 2.3 PL11] Since your scheme relies on symbolic links, it won't work on many systems. If you want a cache, then I think a purely memory-based cache would be better. Simply arrange to clear the cache when $path is assigned to. No new variables, no new builtins required. DaviD W. Sanderson (dws@cs.wisc.edu) From rc-owner Sat Feb 8 08:36:48 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <45331>; Sat, 8 Feb 1992 08:34:40 -0600 Received: by doolittle.vetsci.su.oz.au id <49450>; Sun, 9 Feb 1992 01:34:09 +1100 From: John (I've got some bad news for you, sunshine) Mackin Date: Sat, 8 Feb 1992 08:32:51 -0600 To: The rc Mailing List Subject: Re: path caching In-Reply-To: <199202081101.AA05781@cerberus.bhpese.oz.au> Message-ID: <199202090132.1752.rc.bafad@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Comments ? Yes. If you want this sort of tripe please be so kind as to use some other shell. OK, John. From rc-owner Sat Feb 8 09:46:43 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45329>; Sat, 8 Feb 1992 09:44:39 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA25304; Sat, 8 Feb 92 16:44:11 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA04972; Sat, 8 Feb 92 16:44:09 +0100 Date: Sat, 8 Feb 1992 09:44:09 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202081544.AA04972@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: Re: first impressions rc 1.3beta In-Reply-To: Mail from 'schwartz@groucho.cs.psu.edu' dated: Fri, 7 Feb 1992 14:21:10 -0600 There some minor defficiencies to editline, I already started hacking it: 1) cntl-L should not just reprint the current line, but clear the whole screen. This requires termcap capabilities (done). 2) Because I prefer to keep long commands on one line, I increased the maximum line length. In situations when the terminal is smaller than the line length, the implementation of fails to redraw the correctly (to be done). Also cntl-L fails (done). Btw, what is the email address of Simmule R. Turner ?? Malte. From rc-owner Sat Feb 8 10:02:23 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45329>; Sat, 8 Feb 1992 09:58:56 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA25352; Sat, 8 Feb 92 16:58:41 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA05001; Sat, 8 Feb 92 16:58:40 +0100 Date: Sat, 8 Feb 1992 09:58:40 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202081558.AA05001@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: Re: first impressions rc 1.3beta In-Reply-To: Mail from 'dws@cs.wisc.edu (DaviD W. Sanderson)' dated: Sat, 8 Feb 92 9:52:34 CST Correct me if I'm wrong, but isn't cntl-L the form feed character? And how would you issue a clear command while editing a line? Malte. From rc-owner Sat Feb 8 10:14:09 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45329>; Sat, 8 Feb 1992 10:08:56 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA25383; Sat, 8 Feb 92 17:08:36 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA05029; Sat, 8 Feb 92 17:08:35 +0100 Date: Sat, 8 Feb 1992 10:08:35 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202081608.AA05029@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: editline I have just changed my terminal and noticed that editline cannot be used together with screen ( a program which multiplexes many logical terminals on a physical one). The cursor keys don't work anymore. Just to give it a mention .. Malte. From rc-owner Sat Feb 8 10:48:36 1992 Received: by archone.tamu.edu id <45330>; Sat, 8 Feb 1992 10:38:35 -0600 From: Byron Rakitzis To: rc Subject: Re: first impressions rc 1.3beta Message-Id: <92Feb8.103835cst.45330@archone.tamu.edu> Date: Sat, 8 Feb 1992 10:38:23 -0600 Simmy's address is "simmy@capitol.com", or otherwise "uunet.uu.net!capitol!sysgo!simmy". Also, one thing: right now editline runs under System V as well as BSD; it would be a shame to arbitrarily restrict its use to one of those systems, or worse, provide essentially 2 copies of editline, interlaced with #ifdef, to work on both systems. Is there a good way out of this dilemma? (I guess I'm thinking about struct sgttyb here) From rc-owner Sat Feb 8 11:29:55 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45332>; Sat, 8 Feb 1992 11:20:46 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2718>; Sat, 8 Feb 1992 12:20:02 -0500 To: The rc Mailing List Subject: Re: path caching In-reply-to: Sm's message of Sat, 08 Feb 92 17:01:07 -0500. <199202081101.AA05781@cerberus.bhpese.oz.au> Date: Sat, 8 Feb 1992 11:19:56 -0600 From: Chris Siebenmann Message-Id: <92Feb8.122002est.2718@hawkwind.utcs.toronto.edu> How many times the path cache 'hit' is uninteresting; the performance number wanted is how much time it saved. If you can show a definite useful time saving in a typical shell-script/user's session/whatever it might be interesting; otherwise, it's just gratuitous complexity. - cks From rc-owner Sat Feb 8 15:57:44 1992 Received: from Princeton.EDU ([128.112.128.1]) by archone.tamu.edu with SMTP id <45333>; Sat, 8 Feb 1992 15:34:12 -0600 Received: from and.Princeton.EDU by Princeton.EDU (5.65b/2.85/princeton) id AA27407; Sat, 8 Feb 92 16:33:13 -0500 Received: by math.princeton.edu (4.0/1.110) id AA23376; Sat, 8 Feb 92 16:33:11 EST Date: Sat, 8 Feb 1992 15:33:11 -0600 Message-Id: <9202082133.AA23376@math.princeton.edu> From: rjc@math.Princeton.EDU (Raymond Chen) To: rc@archone.tamu.edu Subject: Re: Ctrl-L in editline malte@techfak.uni-bielefeld.de claims that Ctrl-L should clear the entire screen instead of merely redrawing the current line. I forcefully disagree. Why should Ctrl-L clear the screen? Ctrl-L in emacs, vi, and most curses-based programs is the ``redraw current screen'' command, not the ``clear current screen'' command. Since editline's ``screen'' is but a single line, it should redraw only that line. Imagine: I've just received a `talk' request. My friend Byron is coming in from a machine I've never seen before with a complicated name, so I have to type his address in very carefully. talk tbrakitz@phoe and *BLAM* some line noise hits my modem. I want to get rid of the line noise, so I type Ctrl-L to get readline to reprint my current command. But wait, that Ctrl-L also zapped my current screen! Ugh, that also erased byron's address! I'm hosed! If you want the screen to clear, type ``clear''. Thank you. ObRcHack: Set your prompt to prompt = ('; ' ':\010') This way, continuation lines are prompted with a `:', but the `:' is erased by your typing. You get the benefit of a prompt (to let you know you miscounted your quotation marks), yet the prompt doesn't stop you from snarfing-and-barfing. (If you want to type a blank line, remember to type `space backspace enter' instead.) From rc-owner Sat Feb 8 16:43:31 1992 Received: by archone.tamu.edu id <45337>; Sat, 8 Feb 1992 16:37:47 -0600 From: Byron Rakitzis To: rc Subject: patch to builtins.c, when compiling with -DNOLIMITS Message-Id: <92Feb8.163747cst.45337@archone.tamu.edu> Date: Sat, 8 Feb 1992 16:36:43 -0600 Several people noticed this error, so I thought I'd send a patch to the list to stave off any more identical bug reports! *** builtins.c~ Sat Feb 8 14:06:17 1992 --- builtins.c Sat Feb 8 14:32:24 1992 *************** *** 40,46 **** --- 40,48 ---- { b_eval, "eval" }, { b_exec, "exec" }, { b_exit, "exit" }, + #ifndef NOLIMITS { b_limit, "limit" }, + #endif { b_newpgrp, "newpgrp" }, { b_return, "return" }, { b_shift, "shift" }, From rc-owner Sat Feb 8 16:56:04 1992 Received: from eros.uknet.ac.uk ([192.91.199.2]) by archone.tamu.edu with SMTP id <45336>; Sat, 8 Feb 1992 16:53:15 -0600 Received: from ibmpcug.co.uk by eros.uknet.ac.uk with UUCP id <8247-0@eros.uknet.ac.uk>; Sat, 8 Feb 1992 22:53:23 +0000 Received: by ibmpcug.co.uk (smail2.5) id AA05486; 8 Feb 92 22:49:45 GMT (Sat) X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: rc@archone.tamu.edu Subject: editline Message-Id: <9202082249.AA05482@ibmpcug.co.uk> Date: Sat, 8 Feb 1992 16:49:44 -0600 From: Matthew Farwell What would be nice would if editline were to merge matching commands, to save space etc, like ; ls ; foobar ; foobar ; plop ; plop ; plop ; ls The history would consist of ls foobar plop ls I haven't looked at the code just yet, so I don't know how hard this would be to arrange (whats a strcmp between friends?). It might be a good idea for normal rc as well. Dylan. From rc-owner Sat Feb 8 21:18:39 1992 Received: from munnari.oz.au ([128.250.1.21]) by archone.tamu.edu with SMTP id <45329>; Sat, 8 Feb 1992 21:07:34 -0600 Received: from cerberus.bhpese.oz (via metro) by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA17368; Sun, 9 Feb 1992 14:07:13 +1100 (from Sm@cerberus.bhpese.oz.au) Received: from localhost by cerberus.bhpese.oz.au with ELM 2.3 PL5 id AA27425; Sun, 9 Feb 1992 14:06:09 +1100; sendmail 5.65c/Sm3.0RMSU (from Sm@cerberus.bhpese.oz.au for rc@archone.tamu.edu@munnari.oz.au) Message-Id: <199202090306.AA27425@cerberus.bhpese.oz.au> From: Scott Merrilees Subject: Re: path caching To: rc@archone.tamu.edu (The rc Mailing List) Date: Sun, 9 Feb 1992 08:06:08 -0600 In-Reply-To: <92Feb8.122002est.2718@hawkwind.utcs.toronto.edu>; from "Chris Siebenmann" at Feb 8, 92 11:19 am X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" How many times the path cache 'hit' is uninteresting; the > performance number wanted is how much time it saved. If > you can show a definite useful time saving in a typical > shell-script/user's session/whatever it might be interesting; > otherwise, it's just gratuitous complexity. > - cks Defining a typical shell-script/user's session/whatever is rather difficult, I'm in the just about to start a trial period of two weeks of cache use, followed by two weeks of non-cache use. I'll let you know the results, but I would think that the results would vary greatly with the composition of the path, eg number of components, size of directories, whether components are network accessed, order of path, ram disc based cache etc. Sm -- Scott Merrilees, BHP Information Technology, Newcastle, Australia Internet: Sm@bhpese.oz.au Phone: +61 49 40 2132 Fax: ... 2165 From rc-owner Sat Feb 8 21:28:37 1992 Received: from munnari.oz.au ([128.250.1.21]) by archone.tamu.edu with SMTP id <45332>; Sat, 8 Feb 1992 21:18:48 -0600 Received: from cerberus.bhpese.oz (via metro) by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA17474; Sun, 9 Feb 1992 14:17:42 +1100 (from Sm@cerberus.bhpese.oz.au) Received: from localhost by cerberus.bhpese.oz.au with ELM 2.3 PL5 id AA27658; Sun, 9 Feb 1992 14:15:48 +1100; sendmail 5.65c/Sm3.0RMSU (from Sm@cerberus.bhpese.oz.au for rc@archone.tamu.edu@munnari.oz.au) Message-Id: <199202090315.AA27658@cerberus.bhpese.oz.au> From: Scott Merrilees Subject: Re: path caching To: rc@archone.tamu.edu (The rc Mailing List) Date: Sun, 9 Feb 1992 08:15:47 -0600 In-Reply-To: <9202081331.AA07997@skinner.cs.wisc.edu>; from "DaviD W. Sanderson" at Feb 8, 92 7:31 am X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" DaviD W. Sanderson (dws@cs.wisc.edu) > Since your scheme relies on symbolic links, it won't work on many > systems. Something I am prepared to wear, as the machines I mostly want to use do have symlinks. > If you want a cache, then I think a purely memory-based cache would be > better. This is neither persistant, sharable nor externally user manipulable. > Simply arrange to clear the cache when $path is assigned to. > No new variables, no new builtins required. Then I have to modify both the path lookup code & the variable lookup code. I didn't want the rest of the shell to know about it. Anyway, it will be more interesting when I have some data from the trial I am running. Sm -- Scott Merrilees, BHP Information Technology, Newcastle, Australia Internet: Sm@bhpese.oz.au Phone: +61 49 40 2132 Fax: ... 2165 From rc-owner Sat Feb 8 21:41:20 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45330>; Sat, 8 Feb 1992 21:35:00 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2732>; Sat, 8 Feb 1992 22:34:41 -0500 To: rc@archone.tamu.edu Subject: Re: editline In-reply-to: dylan's message of Sat, 08 Feb 92 17:49:44 -0500. <9202082249.AA05482@ibmpcug.co.uk> Date: Sat, 8 Feb 1992 21:34:38 -0600 From: Chris Siebenmann Message-Id: <92Feb8.223441est.2732@hawkwind.utcs.toronto.edu> I once put 'merge command sequences' into a history recall (in fact, wrote it in in the first place). After a month or so of use, I ripped it out and was much happier. My experience was that it causes a 'dissonance'; what you remember typing is not what you will get with command recall, and this fouls up one's reflexes. I would heavily recommend against adding this feature. - cks From rc-owner Sun Feb 9 01:00:19 1992 Received: by archone.tamu.edu id <45333>; Sun, 9 Feb 1992 00:47:43 -0600 From: Byron Rakitzis To: rc Subject: echo builtin Message-Id: <92Feb9.004743cst.45333@archone.tamu.edu> Date: Sun, 9 Feb 1992 00:47:37 -0600 Should echo use getopt(3)? It seems like overkill, and yet it would make echo consistent with whatis, and indeed with rc's initialization. However, it bothers me that echo -f would draw an error. Opinions? If you like, you can mail to me and I will summarize to the list. From rc-owner Sun Feb 9 04:48:10 1992 Received: from relay2.UU.NET ([137.39.1.7]) by archone.tamu.edu with SMTP id <45334>; Sun, 9 Feb 1992 04:42:17 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17923; Sun, 9 Feb 92 05:42:14 -0500 Received: from capitol.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 054154.18879; Sun, 9 Feb 1992 05:41:54 EST Received: from sysgo.UUCP by (4.0/SMI-4.0) id AA06921; Sun, 9 Feb 92 04:15:48 EST Received: by sysgo.uucp (UMAIL 3.3/MINIX) with UUCP; Sat, 8 Feb 92 23:10:18 EST +0500 Message-Id: <920208.AA0151@sysgo.uucp> Date: Sat, 8 Feb 1992 16:51:19 -0600 From: capitol!sysgo!simmy@uunet.UU.NET (Simmule Turner) Subject: Re: Re: first impressions rc 1.3beta To: rc@archone.tamu.edu techfak.uni-bielefeld.de!malte writes: >1) cntl-L should not just reprint the current line, but clear the > whole screen. This requires termcap capabilities (done). Why not just use a macro, that is bound to say 'ESC L'. _L_=^A^Kclear^M^Y Simmule Turner simmy@capitol.com simmy@sysgo.UUCP%capitol.com From rc-owner Sun Feb 9 13:02:55 1992 Received: from eros.uknet.ac.uk ([192.91.199.2]) by archone.tamu.edu with SMTP id <45329>; Sun, 9 Feb 1992 12:58:36 -0600 Received: from ibmpcug.co.uk by eros.uknet.ac.uk with UUCP id <18897-0@eros.uknet.ac.uk>; Sun, 9 Feb 1992 18:59:09 +0000 Received: by ibmpcug.co.uk (smail2.5) id AA05996; 9 Feb 92 18:55:48 GMT (Sun) X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. In-Reply-To: <199202081101.AA05781@cerberus.bhpese.oz.au> Organization: The IBM PC User Group, UK. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: rc@archone.tamu.edu Subject: Re: path caching Message-Id: <9202091855.AA05991@ibmpcug.co.uk> Date: Sun, 9 Feb 1992 12:55:47 -0600 From: Matthew Farwell In article <199202081101.AA05781@cerberus.bhpese.oz.au> you write: >I've been playing with the idea of a file system based path cache, as >my path is rather long. Enclosed is some doco I wrote on the caching, >and accompanying instrumentation. This is currently for rc 1.2, I am >just about to post it to 1.3b. Comments ? > >[ deleted ] Why can't you do something like: This is untested, since I don't have symbolic links. cache = $home/.cache fn rehash { for (i in $path) { @{ cd $i for (j in *) { if (! test -x $cache/$j) ln -s $i/$j $cache/$j } } } } or something like that. Then you only require one directory in your path, ie $cache. Dylan. From rc-owner Sun Feb 9 20:39:04 1992 Received: from munnari.oz.au ([128.250.1.21]) by archone.tamu.edu with SMTP id <45330>; Sun, 9 Feb 1992 20:35:34 -0600 Received: from cerberus.bhpese.oz (via metro) by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA12126; Mon, 10 Feb 1992 13:35:13 +1100 (from Sm@cerberus.bhpese.oz.au) Received: from localhost by cerberus.bhpese.oz.au with ELM 2.3 PL5 id AA26625; Mon, 10 Feb 1992 13:34:47 +1100; sendmail 5.65c/Sm3.0RMSU (from Sm@cerberus.bhpese.oz.au for rc@archone.tamu.edu@munnari.oz.au) Message-Id: <199202100234.AA26625@cerberus.bhpese.oz.au> From: Scott Merrilees Subject: Re: path caching To: rc@archone.tamu.edu (The rc Mailing List) Date: Mon, 10 Feb 1992 07:34:46 -0600 In-Reply-To: <9202091855.AA05991@ibmpcug.co.uk>; from "Matthew Farwell" at Feb 9, 92 12:55 pm X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" Why can't you do something like: > This is untested, since I don't have symbolic links. > cache = $home/.cache > fn rehash { > for (i in $path) { > @{ cd $i > for (j in *) { > if (! test -x $cache/$j) ln -s $i/$j $cache/$j > } > } > } > } Possible, but I wanted to keep the size of the cache down, so directory lookups are quicker. If I did the above, I would have one directory with approx 1800 entries. I would also have name clashes with system v vs bsd vs gnu stuff. Still it may be worth testing. Sm -- Scott Merrilees, BHP Information Technology, Newcastle, Australia Internet: Sm@bhpese.oz.au Phone: +61 49 40 2132 Fax: ... 2165 From rc-owner Mon Feb 10 15:10:26 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45332>; Mon, 10 Feb 1992 14:47:32 -0600 Received: by groucho.cs.psu.edu id <2604>; Mon, 10 Feb 1992 15:47:09 -0500 From: Scott Schwartz To: rc@archone.tamu.edu Subject: tstp? Message-Id: <92Feb10.154709est.2604@groucho.cs.psu.edu> Date: Mon, 10 Feb 1992 14:46:54 -0600 Fellow users of systems with job control... what do you do about tstp? I hate hitting ctrl-z by accident and having something get nuked. For a while I was putting ``/bin/stty susp undef dsusp undef ixany'' in my .rcrc. These days ``fn sigtstp {}'' seems better. Any advice? From rc-owner Mon Feb 10 20:41:08 1992 Received: from relay2.UU.NET ([137.39.1.7]) by archone.tamu.edu with SMTP id <45329>; Mon, 10 Feb 1992 20:31:05 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19015; Mon, 10 Feb 92 21:31:05 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 212958.9949; Mon, 10 Feb 1992 21:29:58 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa04543; Mon, 10 Feb 92 20:53:19 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@archone.tamu.edu Subject: Just how brain dead is SCO Unix? Date: Mon, 10 Feb 1992 19:53:26 -0600 Message-Id: <9202102053.aa29139@ceres.srg.af.mil> While running some test programs through rc to beat it up some I began to wonder what was taking so long. A couple of peeks with ps were enough to make me feel quite ill. In SCO Unix /bin/test is a Bourne shell script that does essentially this: `basename $0` "$@" 8-P Blech! You can at least avoid running basename by using: fn test { /bin/sh -c test $* } But basically the choice is the test built into your shell (or Bourne shell) or nothing! Any better suggestions are welcome. Tom From rc-owner Mon Feb 10 21:06:16 1992 Received: by archone.tamu.edu via suspension id <45333>; Mon, 10 Feb 1992 21:01:18 -0600 Received: by archone.tamu.edu id <45330>; Mon, 10 Feb 1992 20:51:01 -0600 From: Byron Rakitzis To: rc Subject: Re: Just how brain dead is SCO Unix? Message-Id: <92Feb10.205101cst.45330@archone.tamu.edu> Date: Mon, 10 Feb 1992 20:50:53 -0600 I am sure there is a GNU test out there. Try looking for a "shellutils" package. From rc-owner Tue Feb 11 11:23:45 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45329>; Tue, 11 Feb 1992 11:11:17 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA12307; Tue, 11 Feb 92 18:10:16 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA18988; Tue, 11 Feb 92 18:10:15 +0100 Date: Tue, 11 Feb 1992 11:10:15 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202111710.AA18988@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: alias function in rc I as a nasty sytem administrator, I'm planning to let csh slowly die ( if the users let me, of course! ). I'd like to make rc the standart shell. To make life easier for them I wrote a little rc function which provides the functionality of the common alias definitions. I post it here hoping you will benefit from it. Let me here of bugs and incompabilities! fn alias { fn deffn { name = $^1; shift 1 newfn = 'fn ' ^ $^name ^ ' { builtin ' ^ $^* ^ ' $* }' eval $newfn } switch( $#* ){ case 0; whatis | grep '^fn '; case 1; whatis $^1; case 2; name=() newfn=() deffn $*; case 3; echo 'usage:' $0 '[alias_name [''definition'']]' >[1=2] return 1 } } Malte. From rc-owner Tue Feb 11 20:54:36 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45330>; Tue, 11 Feb 1992 20:44:48 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2668>; Tue, 11 Feb 1992 21:43:41 -0500 To: rc@archone.tamu.edu Subject: oddity with rc (1.3b and 1.2) Date: Tue, 11 Feb 1992 20:43:13 -0600 From: Chris Siebenmann Message-Id: <92Feb11.214341est.2668@hawkwind.utcs.toronto.edu> If you execute the following { while() echo sss } >rc & sleep 5 ; kill -9 $apid you get an rc, one PID higher than the printed 'background' rc, that doesn't die from the kill. What's going on? Is this an error? If the while becomes a function, it works. Methinks something is just a little bit wrong here. - cks From rc-owner Tue Feb 11 22:47:03 1992 Received: by archone.tamu.edu id <45331>; Tue, 11 Feb 1992 22:38:54 -0600 From: Byron Rakitzis To: rc Subject: redirection bug Message-Id: <92Feb11.223854cst.45331@archone.tamu.edu> Date: Tue, 11 Feb 1992 22:38:44 -0600 Here's the patch to the extra-fork redirection bug that Chris just mentioned: (this patch comprises all the changes made to walk.c since rc-1.3beta, but fortunately there is just one other minor change in addition to this one:) *** beta/walk.c Tue Feb 11 22:35:48 1992 --- walk.c Tue Feb 11 22:23:27 1992 *************** *** 12,18 **** bool cond = FALSE; static bool isallpre(Node *); ! static bool dofork(void); static void dopipe(Node *); /* Tail-recursive version of walk() */ --- 12,18 ---- bool cond = FALSE; static bool isallpre(Node *); ! static bool dofork(bool); static void dopipe(Node *); /* Tail-recursive version of walk() */ *************** *** 42,48 **** case nNowait: { int pid; if ((pid = rc_fork()) == 0) { - int fd; setsigdefaults(); #if defined(SIGTTOU) && defined(SIGTTIN) && defined(SIGTSTP) rc_signal(SIGTTOU, SIG_IGN); /* Berkeleyized version: put it in a new pgroup. */ --- 42,47 ---- *************** *** 52,59 **** #else rc_signal(SIGINT, SIG_IGN); /* traditional backgrounding procedure: ignore SIGINT */ #endif ! fd = rc_open("/dev/null", rFrom); ! mvfd(fd, 0); walk(n->u[0].p, FALSE); exit(getstatus()); } --- 51,57 ---- #else rc_signal(SIGINT, SIG_IGN); /* traditional backgrounding procedure: ignore SIGINT */ #endif ! mvfd(rc_open("/dev/null", rFrom), 0); walk(n->u[0].p, FALSE); exit(getstatus()); } *************** *** 141,147 **** break; } case nSubshell: ! if (dofork()) { setsigdefaults(); walk(n->u[0].p, TRUE); rc_exit(getstatus()); --- 139,145 ---- break; } case nSubshell: ! if (dofork(TRUE)) { setsigdefaults(); walk(n->u[0].p, TRUE); rc_exit(getstatus()); *************** *** 233,239 **** case nBrace: if (n->u[1].p == NULL) { WALK(n->u[0].p, TRUE); ! } else if (dofork()) { setsigdefaults(); walk(n->u[1].p, TRUE); /* Do redirections */ redirq = NULL; /* Reset redirection queue */ --- 231,237 ---- case nBrace: if (n->u[1].p == NULL) { WALK(n->u[0].p, TRUE); ! } else if (dofork(parent)) { setsigdefaults(); walk(n->u[1].p, TRUE); /* Do redirections */ redirq = NULL; /* Reset redirection queue */ *************** *** 273,283 **** waits for the child to finish, setting $status appropriately. */ ! static bool dofork() { void (*handler)(int); int pid, sp; ! if ((pid = rc_fork()) == 0) return TRUE; redirq = NULL; /* clear out the pre-redirection queue in the parent */ fifoq = NULL; --- 271,281 ---- waits for the child to finish, setting $status appropriately. */ ! static bool dofork(bool parent) { void (*handler)(int); int pid, sp; ! if (!parent || (pid = rc_fork()) == 0) return TRUE; redirq = NULL; /* clear out the pre-redirection queue in the parent */ fifoq = NULL; From rc-owner Wed Feb 12 01:49:51 1992 Received: by archone.tamu.edu id <45332>; Wed, 12 Feb 1992 01:43:08 -0600 From: Byron Rakitzis To: rc Subject: the great echo controversy Message-Id: <92Feb12.014308cst.45332@archone.tamu.edu> Date: Wed, 12 Feb 1992 01:43:05 -0600 I received about 10 replies; half in favor of a v7-style echo (-n, no getopt), half in favor of a getopt() echo. I decided to go with a getopt echo, if only because it's consistent. I can't believe I'm making a mountain out of a molehill with this but endless debates about echo seem to be a Unix tradition :-) Byron. PS For people who don't like to get much rc mail, I apologize. I imagine things will calm down once more after 1.3 is released. From rc-owner Wed Feb 12 10:55:59 1992 Received: from relay2.UU.NET ([137.39.1.7]) by archone.tamu.edu with SMTP id <45332>; Wed, 12 Feb 1992 10:43:31 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14959; Wed, 12 Feb 92 11:43:15 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 114129.12113; Wed, 12 Feb 1992 11:41:29 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa28353; Wed, 12 Feb 92 11:37:42 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: byron@archone.tamu.edu, rc@archone.tamu.edu Subject: Re: redirection bug Date: Wed, 12 Feb 1992 10:37:54 -0600 Message-Id: <9202121137.aa04813@ceres.srg.af.mil> >> Here's the patch to the extra-fork redirection bug that Chris just >> mentioned: >> >> (this patch comprises all the changes made to walk.c since rc-1.3beta, >> but fortunately there is just one other minor change in addition to this >> one:) I'm confused. Do you mean that this is a patch for Chris's bug plus one other minor thing or that there is one other minor patch to 1.3beta beside this? (maybe the patch for builtin.c?) In any case 1.3beta has held up quite well to substantial abuse aside from the oddness with SIGINT I noted earlier. As a side note I've collected several hints for other SCO Unix users if anyone is intrested, everything from patches to system include files to small rc functions that improve speed substantially. For example, fn true { return 0 } is a big win vs. firing up the Bourne shell every time through a loop with "while (true)". Tom From rc-owner Wed Feb 12 11:17:06 1992 Received: by archone.tamu.edu id <45337>; Wed, 12 Feb 1992 11:08:27 -0600 From: Byron Rakitzis To: rc Subject: more echo controversy Message-Id: <92Feb12.110827cst.45337@archone.tamu.edu> Date: Wed, 12 Feb 1992 11:08:23 -0600 Ok, for the getopt fans: args=(-O -g) echo -n $args or even echo $args draws an error. Is this sensible, let alone desirable? From rc-owner Wed Feb 12 11:27:43 1992 Received: from nac.no ([129.240.2.40]) by archone.tamu.edu with SMTP id <45338>; Wed, 12 Feb 1992 11:20:33 -0600 Received: by nac.no (5.64+IDA/Babel-1.6/6.0) id AAnac07447; Wed, 12 Feb 1992 18:19:22 +0100 Received: by bibsyst.no (/\==/\ Smail3.1.21.1 #21.19) id ; Wed, 12 Feb 92 14:19 WET Message-Id: From: tore@bibsyst.no (Tore Morkemo) Subject: smart rm fn... To: rc@archone.tamu.edu (rc list) Date: Wed, 12 Feb 1992 08:19:14 -0600 X-Mailer: ELM [version 2.3 PL11] -- Hei ! I just got the idea of writing a smart rm function but I havent got too much exeperience in writing rc scripts, maybe one of you rc-gurus could take this as an exercise. I don't like the idea of fn'ing rm to move the file to /tmp or somewhere else ( fn rm {mv $* /tmp} ) since this tend to fill up /tmp. But I have to admit that I just removed a file that I shouldn't have removed....:-( So what about this idea: Make a fn that REMOVES only the files that I never need, like .o files, and MOVES all the files that ends with .c .h etc. to /tmp. The file extensions that I would like to move should be put in a list like : move_file_extensions=(.c .h .1 .C .cpp) PS: Actually I just came up with a better solution to the entire problem, but I still think it's a good rc exercise and I would like to see a good solution..... Tore. +----------------------------------------------------------------------+ ! Tore Morkemo, Bibliotek-Systemer A/S, N-3250 Larvik, Norway ! ! uucp: ...!bibsyst.no!tore Tel: +47 34 82 202 ! ! tore@bibsyst.no Fax: +47 34 85 185 ! +----------------------------------------------------------------------+ From rc-owner Wed Feb 12 11:40:57 1992 Received: by archone.tamu.edu id <45332>; Wed, 12 Feb 1992 11:34:14 -0600 From: Byron Rakitzis To: rc, tore@bibsyst.no Subject: Re: smart rm fn... Message-Id: <92Feb12.113414cst.45332@archone.tamu.edu> Date: Wed, 12 Feb 1992 11:34:01 -0600 This is just off the top of my head, but the problem is exactly suited for the ~ operator: fn rm { for (i) { if (~ $i *^$move_file_extensions) { mv $i /tmp/save_dir } else { builtin rm $i } } } There, how's that? (you'll want to add options etc. but I haven't got time right now) From rc-owner Wed Feb 12 14:34:53 1992 Received: from eros.uknet.ac.uk ([192.91.199.2]) by archone.tamu.edu with SMTP id <45338>; Wed, 12 Feb 1992 14:28:35 -0600 Received: from ibmpcug.co.uk by eros.uknet.ac.uk with UUCP id <29792-0@eros.uknet.ac.uk>; Wed, 12 Feb 1992 20:28:42 +0000 Received: by ibmpcug.co.uk (smail2.5) id AA03509; 12 Feb 92 17:32:40 GMT (Wed) X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. Newsgroups: list.rc In-Reply-To: <199202100234.AA26625@cerberus.bhpese.oz.au> Organization: The IBM PC User Group, UK. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: rc@archone.tamu.edu Subject: Re: path caching Message-Id: <9202121732.AA03504@ibmpcug.co.uk> Date: Wed, 12 Feb 1992 11:32:39 -0600 From: Matthew Farwell In article <199202100234.AA26625@cerberus.bhpese.oz.au> you write: >> Why can't you do something like: >> This is untested, since I don't have symbolic links. >> cache = $home/.cache >> fn rehash { >> for (i in $path) { >> @{ cd $i >> for (j in *) { >> if (! test -x $cache/$j) ln -s $i/$j $cache/$j >> } >> } >> } >> } > >Possible, but I wanted to keep the size of the cache down, so >directory lookups are quicker. If I did the above, I would have one >directory with approx 1800 entries. I would also have name clashes >with system v vs bsd vs gnu stuff. Still it may be worth testing. You still have the name clashes anyway. Dylan. From rc-owner Thu Feb 13 14:10:15 1992 Received: from po2.andrew.cmu.edu ([128.2.249.105]) by archone.tamu.edu with SMTP id <45329>; Thu, 13 Feb 1992 14:03:37 -0600 Received: by po2.andrew.cmu.edu (5.54/3.15) id for rc@archone.tamu.edu; Thu, 13 Feb 92 15:03:06 EST Received: via switchmail; Thu, 13 Feb 1992 15:02:55 -0500 (EST) Received: from lira.mg.andrew.cmu.edu via qmail ID ; Thu, 13 Feb 1992 15:02:10 -0500 (EST) Date: Thu, 13 Feb 1992 14:02:07 -0600 From: "Julian L. Ho" Subject: 1.3b bug? To: rc@archone.tamu.edu Message-Id: <698011327.5687.0@lira.mg.andrew.cmu.edu> Sorry about includeing raw control characters in my last post. I had meant to use cat -v... Anyway, if I . (source) this file, then spawn a new rc, the functions - and -- are no longer there...they are replaced by things that seem very wrong. I wrote this when composing my last message, using 1.2. rc 1.3b doesn't like it. -J begin 644 hist M9FX@+2 M+2![(&,]*"D@>PH@(" @8R ](&!@("@I('L@+7 @)"H@?0H*(" @ M(&EF("A^("0P("TM*2!H/2]T;7 O:&ES(%X@)'!I9"!["@EE8VAO("UN("1C M(#XD: H)15A)3DE4/2=M87 @%@T@6EI\;6%P(2 6#2 6&UI:)R!<"@D@(" @ M97@@*V]P96X@)&@*"6,@/2!@8" H*2![(&-A=" D:"!]"@ER;2 M9B D: H) M:68@*"$@?B D(V,@,"D*"2 @("!E8VAO("UN("1C(#X^)&AI; Thu, 13 Feb 1992 16:20:04 -0600 Received: by uucp-gw-1.pa.dec.com; id AA05130; Thu, 13 Feb 92 13:25:22 -0800 Received: from utopia.adobe.com by adobe.com (4.1/SMI-4.1) id AA10381; Thu, 13 Feb 92 13:20:26 PST Received: by utopia.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA06551; Thu, 13 Feb 92 13:20:23 PST Date: Thu, 13 Feb 1992 15:20:23 -0600 From: haahr@adobe.com Message-Id: <9202132120.AA06551@utopia.adobe.com> Received: by NeXT Mailer (1.63) To: rc mailing list Subject: why i liked rc1.2's echo... [or ``why i'm not letting the great echo controversy just die''] i'm pushing Byron to leave echo as it was in rc-1.3beta and before, and he suggested bringing the issue up with the list because there were many opinions on what echo should do, with everyone arguing for completely different things. here are the possibilities, as i see them for echo: (1) not builtin (2) v7 behavior (-n is recognized if first argument) (3) getopt (accepting only -n and the -- end of options sequence) (4) rc-1.2 and earlier behavior (-n and -- recognized if first) one could also consider system v ism \ sequences but that seems way wrong to me, or the v8/v9/v10 -e flag to give system v behavior. (1) has the advantage that it removes debates on the behavior of echo from this list, and let's everyone pick for themselves. on the other hand, it makes rc scripts that ever invoke echo less portable, and the performance consquences are noticable. (before people start shouting at me that i shouldn't be able to notice the difference between builtin echo and /bin/echo, my machine is rated ~12 specmarks, i'm almost always the only user logged in, and i can feel a difference between rc scripts that exec and those that don't, in a big way.) moreover, i'd argue, and this is more controversial, that a builtin echo makes sense, because it is the complementary operation to backquoting. (2) well, this has the advantage of history, and it's relatively easy to understand. the problem with it is that there is no easy way to echo arbitrary text that might start with the word "-n"; you have to do something on the order of echo -n $^*^$nl or echo -n $*; echo neither of which is very pretty. (3) normally i'm a getopt booster, but i find that adding getopt for echo is just plain unpleasant, because i do use echo without -- occaisonally and don't want to get annoying error messages along the way. at one point when i was using the v8 shell on a system v machine i wrote my own v8/v9/v10 style echo and used getopt for it. within a day or two (probably after the second time i wrote echo --- foo --- or a relative) i threw out the getopt parsing and explicitly looked for option sequences. i'm all for consistency, but echo with getopt seems like a hobgoblin for little minds to me. (4) this is my favorite, for the simple reason that it solves the problem mentioned in (2) without much overhead. for getopt fans, think of it as getopt that's lenient in accepting the end of options. for v7 fans, think of it as one extra option, which says: quote the following string. [alright, it's not really getopt, since normal getopt would imply that echo -n foo echo -n -- foo echo -n -n -n -n foo would all be the same whereas rc-1.2 echo just looked at the first argument.] ----- if we were starting all over again, and wanted to really invent something completely new, i'd just have two echo-like builtins echo $* # behaves like echo -- $* echo-n $* # behaves like echo -n $* because i don't think echo should parse its arguments at all. i really do think of echo as a primitive operation, at the same level as backquoting or variable assignment, and very few people would accept things like foo=(noexport a b c) where assignment parsed its first argument. on the other hand, even i wouldn't want to be that incompatible, i'd say (4) above is really pretty clean and gives the necessary functionality. and, heck, even posix.2 doesn't specify getopt for echo. what posix does say is ``string A string to be written to standard output. If the first operand is "-n" or if any operands contain a backslash (\) character, the results are implementation defined.'' which is a major punt, but of the behaviors i've considered, only (2) would be acceptable. they say "use printf(1)" sorry if i've been long winded, but it seems a shame to me to change rc from doing THE right thing to anything else. imho, of course. From rc-owner Thu Feb 13 17:21:58 1992 Received: from po3.andrew.cmu.edu ([128.2.12.31]) by archone.tamu.edu with SMTP id <45329>; Thu, 13 Feb 1992 17:16:59 -0600 Received: by po3.andrew.cmu.edu (5.54/3.15) id for rc@archone.tamu.edu; Thu, 13 Feb 92 18:16:38 EST Received: via switchmail; Thu, 13 Feb 1992 18:16:35 -0500 (EST) Received: from unix2.andrew.cmu.edu via qmail ID ; Thu, 13 Feb 1992 18:14:35 -0500 (EST) Date: Thu, 13 Feb 1992 17:14:25 -0600 From: "Julian L. Ho" Subject: Re: 1.3b bug? To: rc@archone.tamu.edu Message-Id: <698022865.10787.0@unix2.andrew.cmu.edu> Well, there is no bug in rc. Both the compilers available to me were doing bad things. Thank you Chris Siebenmann for pointing me to a compiler that works (gcc140). -J From rc-owner Thu Feb 13 19:31:38 1992 Received: from munnari.oz.au ([128.250.1.21]) by archone.tamu.edu with SMTP id <45329>; Thu, 13 Feb 1992 19:27:15 -0600 Received: from cerberus.bhpese.oz (via metro) by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA28985; Fri, 14 Feb 1992 12:27:00 +1100 (from Sm@cerberus.bhpese.oz.au) Received: from localhost by cerberus.bhpese.oz.au with ELM 2.3 PL5 id AA24097; Fri, 14 Feb 1992 12:26:49 +1100; sendmail 5.65c/Sm3.0RMSU (from Sm@cerberus.bhpese.oz.au for rc@archone.tamu.edu@munnari.oz.au) Message-Id: <199202140126.AA24097@cerberus.bhpese.oz.au> From: Scott Merrilees Subject: Re: why i liked rc1.2's echo... To: rc@archone.tamu.edu (The rc Mailing List) Date: Fri, 14 Feb 1992 06:26:46 -0600 X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" [or ``why i'm not letting the great echo controversy just die''] Or you could do something I first heard espoused by Robert Elz (kre@munnari), that echo should just echo its arguments, kind of like a permanent -n. So to get -n behavoiur, do echo string and to get normal echo behavoiur, use echo 'string ' This has that advantage that it is extremely simple & consistant. Sm From rc-owner Thu Feb 13 23:22:45 1992 Received: by archone.tamu.edu id <45338>; Thu, 13 Feb 1992 23:20:05 -0600 From: Byron Rakitzis To: rc Subject: configuration parameters Message-Id: <92Feb13.232005cst.45338@archone.tamu.edu> Date: Thu, 13 Feb 1992 23:19:54 -0600 rc's configuration has become unweildy. I want to try something cleaner than that ugly makefile. Is the solution shown below satisfactory? (the file that follows replaces the current config.h:) /* * Configuration parameters for rc. Suggested defaults are at the bottom * of this file (you should probably look at those first to see if your * system matches one of them; you can search for the beginning of the * defaults section by looking for the string "#ifndef CUSTOM"). If you * want to override the suggested defaults, define the macro CUSTOM. #define CUSTOM */ /* * (Note that certain default settings redefine this macro) * DEFAULTPATH the default search path that rc uses when it is started * without either a PATH or path environment variable. You must pick * something sensible for your system if you don't like the path shown * below. */ #define DEFAULTPATH "/usr/ucb", "/usr/bin", "/bin", "." /* * Define the macro NODIRENT if your system has but not * . (e.g., NeXT-OS and RISCos) #define NODIRENT */ /* * Define the macro SVSIGS if your system has System V signal semantics, * i.e., if "slow" system calls are interrupted rather than resumed * after returning from an interrupt handler. (If you are not sure what * this means, see the man page for signal(2). In any case, it is probably * safe to leave this macro undefined.) #define SVSIGS */ /* * Define the macro NOCMDARG if you do not have /dev/fd or fifos on your * system. You may also want to define this if you have broken fifos. * For example, if you have a Sun with /tmp mounted as a ramdisk * (type "tmpfs") then you cannot use fifos in /tmp (sigh). #define NOCMDARG */ /* * Define the macro DEVFD if your system supports /dev/fd. #define DEVFD */ /* * Define the macro NOLIMITS if your system does not support Berkeley * limits. #define NOLIMITS */ /* * Define the macro NOSIGCLD if your system uses SIGCLD in the System * V way. (e.g., sgi's Irix) #define NOSIGCLD */ /* * Define the macro READLINE if you want rc to call GNU readline * instead of read(2) on interactive shells. #define READLINE */ /* * Define the macro EDITLINE if you want rc to call Simmule Turner's * readline-like library. (it's about 1/10 the size of GNU, but with * fewer options) Also uncomment the EDITLIB variable in the Makefile. #define EDITLINE */ /* * Define the macro NOEXECVE if your Unix does not interpret #! in the * kernel, and uncomment the EXECVE variable in the Makefile. #define NOEXECVE */ /* * If you want rc to default to some interpreter for files which don't * have a legal #! on the first line, define the macro DEFAULTINTERP. #define DEFAULTINTERP "/bin/sh" */ /* * If your /bin/sh (or another program you care about) rejects * environment variables with special characters in them, rc can put * out ugly variable names using [_0-9a-zA-Z] that encode the real * name; define PROTECT_ENV for this hack. (Known offenders: every * sh I have tried; SunOS (silently discards), NeXT (aborts with * error), SGI (aborts with error), Ultrix (sh seems to work, sh5 * aborts with error)) #define PROTECT_ENV */ /* Beginning of defaults section: */ #ifndef CUSTOM /* * Suggested settings for Sun, NeXT and sgi (machines here at TAMU): */ #ifdef NeXT #define NODIRENT #define PROTECT_ENV #define NOCMDARG #endif #ifdef sgi #define SVSIGS #define NOSIGCLD #define PROTECT_ENV #undef DEFAULTPATH #define DEFAULTPATH "/usr/bsd", "/usr/sbin", "/usr/bin", "/bin", "." #endif #ifdef sun #define PROTECT_ENV #undef DEFAULTPATH #define DEFAULTPATH "/usr/ucb", "/usr/bin", "." #endif /* * Suggested settings for HP300 running 4.3BSD-utah (DWS): */ #if defined(hp300) && !defined(hpux) #define NODIRENT #define NOCMDARG #define DEFAULTINTERP "/bin/sh" #define PROTECT_ENV #endif /* * Suggested settings for Ultrix */ #ifdef ultrix #define PROTECT_ENV #define DEFAULTINTERP "/bin/sh" /* so /bin/true can work */ #endif /* * Suggested settings for RiscOS 4.52 */ #ifdef host_mips #define NODIRENT #define PROTECT_ENV extern int errno; /* not defined in the mips !?!?! */ #endif #endif /* CUSTOM */ From rc-owner Thu Feb 13 23:42:04 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45339>; Thu, 13 Feb 1992 23:33:43 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2716>; Fri, 14 Feb 1992 00:33:18 -0500 To: rc@archone.tamu.edu Subject: Re: configuration parameters In-reply-to: byron's message of Fri, 14 Feb 92 00:19:54 -0500. <92Feb13.232005cst.45338@archone.tamu.edu> Date: Thu, 13 Feb 1992 23:33:14 -0600 From: Chris Siebenmann Message-Id: <92Feb14.003318est.2716@hawkwind.utcs.toronto.edu> Actually, I'll disagree here; I think the combination of the Makefile and the 'canned' stuff in config.h has worked fine. It also (importantly!) keeps the number of files one usually has to edit when moving rc from platform to platform down to one (Makefile), which people are used to editing. - cks From rc-owner Fri Feb 14 04:44:55 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 04:39:53 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA26505; Fri, 14 Feb 92 11:24:39 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA04497; Fri, 14 Feb 92 11:24:38 +0100 Date: Fri, 14 Feb 1992 04:24:38 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202141024.AA04497@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: fn : {..} and AIX linker I just tried to compile a C program on an IBM rs6000, AIX 3.1.5. To cut a long story short: I you have a function ":" in your environment, the linker stops with a weird error message. Malte. From rc-owner Fri Feb 14 06:23:22 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 06:18:27 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA26790; Fri, 14 Feb 92 13:18:16 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA04851; Fri, 14 Feb 92 13:18:15 +0100 Date: Fri, 14 Feb 1992 06:18:15 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202141218.AA04851@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: configuration strategy Another suggestion: I have local imake installed, others probably not. An Imakefile would make configuration very clean. Just a thought .. Malte. From rc-owner Fri Feb 14 08:20:39 1992 Received: from pineapple.bbn.com ([128.11.0.16]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 08:15:33 -0600 Received: from litchi.bbn.com by pineapple.bbn.com id ; Fri, 14 Feb 92 09:15:05 -0500 From: Rich Salz Received: by litchi.bbn.com id ; Fri, 14 Feb 92 09:15:02 EST Date: Fri, 14 Feb 1992 08:15:02 -0600 Message-Id: <9202141415.AA06886@litchi.bbn.com> To: byron@archone.tamu.edu Subject: Re: configuration parameters Cc: rc@archone.tamu.edu I think your new scheme is a little better, if only because I find the explanations easier to read (not sure why, I just do). You might want to think about shipping "config.h-dist" and force people to at least review it before copying it into config.h. (People who love the defaults can just symlink it.) If you start using imake, I'll cry. /r$ From rc-owner Fri Feb 14 09:59:24 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 09:56:21 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2537>; Fri, 14 Feb 1992 10:55:50 -0500 To: malte@techfak.uni-bielefeld.de cc: rc@archone.tamu.edu Subject: Re: configuration strategy In-reply-to: Your message of "Fri, 14 Feb 92 07:18:15 EST." <9202141218.AA04851@dahlie.techfak.uni-bielefeld.de> Date: Fri, 14 Feb 1992 09:55:48 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Feb14.105550est.2537@groucho.cs.psu.edu> | Another suggestion: I have local imake installed, others probably not. | An Imakefile would make configuration very clean. I disagree. It would make configuration complicated and dirty, with n^2 more things to deal with. From rc-owner Fri Feb 14 10:19:36 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 10:11:01 -0600 Received: by doolittle.vetsci.su.oz.au id <49376>; Sat, 15 Feb 1992 03:10:39 +1100 From: John (I've got some bad news for you, sunshine) Mackin Date: Fri, 14 Feb 1992 10:09:10 -0600 To: The rc Mailing List Subject: imake Message-ID: <199202150309.7265.rc.bafos@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ imake is the second-worst program in the universe. I'd call it the worst except my mate Brucee doesn't believe in superlatives. OK, John. From rc-owner Fri Feb 14 11:06:39 1992 Received: from harvard.harvard.edu ([128.103.1.1]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 10:58:19 -0600 Received: by harvard.harvard.edu (5.54/a0.25) (for rc@archone.tamu.edu) id AA26184; Fri, 14 Feb 92 11:57:59 EST Received: from gatech.UUCP (uucp.gatech.edu) by gatech.edu (4.1/Gatech-9.1) id AA15554 for archone.tamu.edu!rc; Fri, 14 Feb 92 11:57:23 EST Received: from skeeve.UUCP by gatech.UUCP (4.1/SMI-4.1) id AA29449; Fri, 14 Feb 92 11:56:01 EST Received: by skeeve.ATL.GA.US (smail2.5) id AA02330; 14 Feb 92 09:08:07 EST (Fri) From: gatech!skeeve!arnold@harvard.harvard.edu (Arnold D. Robbins) Date: Fri, 14 Feb 1992 08:08:05 -0600 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: rc@archone.tamu.edu Subject: a standalone test Message-Id: <9202140908.AA02330@skeeve.ATL.GA.US> > From: Byron Rakitzis > Subject: Re: Just how brain dead is SCO Unix? > Date: Mon, 10 Feb 1992 20:50:53 -0600 > > I am sure there is a GNU test out there. Try looking for a "shellutils" > package. Most likely one would have to yank test out of bash, although I have to admit to not having checked the gnu shellutils. (Anyone who thinks ksh is bloated should take a look at bash. Sheesh.) The "right" thing to do (IMHO) is to write a simple ftest program that always takes exactly one option and one argument, and does not do any of the string or number comparisons of /bin/test. ftest -x /bin/rc ftest -w /dev/null and hook things together with the shell's && and || instead of -a and -o. Use ~ or switch for string matching and expr for math. Pardon me if I've stated the obvious. Arnold Robbins -- The Basement Computer | Laundry increases Internet: arnold@skeeve.ATL.GA.US | exponentially in the UUCP: { gatech, emory }!skeeve!arnold | number of children. Bitnet: Forget it. Get on a real network. | -- Miriam Robbins From rc-owner Fri Feb 14 11:24:25 1992 Received: by archone.tamu.edu id <45329>; Fri, 14 Feb 1992 11:16:10 -0600 From: Byron Rakitzis To: rc Subject: GNU test Message-Id: <92Feb14.111610cst.45329@archone.tamu.edu> Date: Fri, 14 Feb 1992 11:15:56 -0600 Rather than bash GNU for no good reason, why not get the facts straight? They may write ugly code, but they write it all the same, and it's out there just for the asking. I hope this is the last mail on the topic: ; ftp gatekeeper.dec.com Connected to gatekeeper.dec.com. 220- *** /etc/motd.ftp *** Gatekeeper.DEC.COM is an unsupported service of DEC Corporate Research. Use entirely at your own risk - no warranty is expressed or implied. Complaints and questions should be sent to . Extended commands available: quote site index PATTERN - to glance through our index here's an example: ftp> quote site index emacs 220 gatekeeper.dec.com FTP server (Version 5.73 Wed Feb 12 18:22:06 PST 1992) ready. 331 Guest login ok, send ident as password. 230 Guest login ok, access restrictions apply. ftp> cd pub/GNU 250 CWD command successful. ftp> ls sh* 200 PORT command successful. 150 Opening ASCII mode data connection for file list. shellutils-1.5.tar.Z shellutils-1.6.tar.Z 226 Transfer complete. remote: sh* 42 bytes received in 0.01 seconds (2.97 Kbytes/s) ftp> bin 200 Type set to I. ftp> get shellutils-1.6.tar.Z 200 PORT command successful. 150 Opening BINARY mode data connection for shellutils-1.6.tar.Z (207665 bytes). 226 Transfer complete. local: shellutils-1.6.tar.Z remote: shellutils-1.6.tar.Z 207665 bytes received in 36.72 seconds (5.52 Kbytes/s) ftp> quit 221 Goodbye. ; zcat *.Z | tar ftv - | grep test rw-rw-rw-9080/1 23320 Jan 20 01:20 1992 shellutils-1.6/src/test.c rw-rw-rw-9080/1 3099 Sep 12 20:16 1991 shellutils-1.6/man/test.1 ; Does this answer everyone's questions? From rc-owner Fri Feb 14 11:50:36 1992 Received: from lisa.cs.widener.edu ([147.31.254.23]) by archone.tamu.edu with SMTP id <45334>; Fri, 14 Feb 1992 11:41:33 -0600 Received: by lisa.cs.widener.edu id AA12880 (5.65c/Widener-4.1 for rc@archone.tamu.edu); Fri, 14 Feb 1992 12:41:25 -0500 Date: Fri, 14 Feb 1992 11:41:25 -0600 From: Brendan Kehoe Message-Id: <199202141741.AA12880@lisa.cs.widener.edu> To: rc@archone.tamu.edu In-Reply-To: Chris Siebenmann's message of Thu, 13 Feb 1992 23:33:14 -0600 <92Feb14.003318est.2716@hawkwind.utcs.toronto.edu> Subject: configuration parameters Reply-To: brendan@cs.widener.edu Date: Thu, 13 Feb 1992 23:33:14 -0600 From: Chris Siebenmann Actually, I'll disagree here; I think the combination of the Makefile and the 'canned' stuff in config.h has worked fine. It also (importantly!) keeps the number of files one usually has to edit when moving rc from platform to platform down to one (Makefile), which people are used to editing. Have you thought of using the GNU configure tool? -- Brendan Kehoe, Sun Network Manager brendan@cs.widener.edu Widener University Chester, PA This is the .signature that Bell Atlantic doesn't want you to see. From rc-owner Fri Feb 14 11:57:53 1992 Received: from harvard.harvard.edu ([128.103.1.1]) by archone.tamu.edu with SMTP id <45341>; Fri, 14 Feb 1992 11:50:53 -0600 Received: by harvard.harvard.edu (5.54/a0.25) (for rc@archone.tamu.edu) id AA27453; Fri, 14 Feb 92 12:45:43 EST Received: from gatech.UUCP (uucp.gatech.edu) by gatech.edu (4.1/Gatech-9.1) id AA16568 for archone.tamu.edu!rc; Fri, 14 Feb 92 12:44:54 EST Received: from skeeve.UUCP by gatech.UUCP (4.1/SMI-4.1) id AA00913; Fri, 14 Feb 92 12:43:32 EST Received: by skeeve.ATL.GA.US (smail2.5) id AA02617; 14 Feb 92 12:37:14 EST (Fri) From: gatech!skeeve!arnold@harvard.harvard.edu (Arnold D. Robbins) Date: Fri, 14 Feb 1992 11:37:12 -0600 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: Byron Rakitzis Subject: gnu bashing - not! Cc: rc@archone.tamu.edu Message-Id: <9202141237.AA02617@skeeve.ATL.GA.US> > From: Byron Rakitzis > To: rc@archone.tamu.edu > Subject: GNU test > Date: Fri, 14 Feb 1992 11:15:56 -0600 > > Rather than bash GNU for no good reason, why not get the facts straight? > They may write ugly code, but they write it all the same, and it's out > there just for the asking. I apologize for giving people the wrong impression --- I was not bashing GNU at all (I'm one of the people doing GNU Awk, for heaven's sake). I *was* bashing on bash, but this is the rc mailing list, where small is beautiful, and bash is neither. There are, or course, some excellent GNU programs, and I use many of them. And I probably should have looked at shellutils, but my poor home machine doesn't have an internet connection (yet :-). Apologies again; last word on the subject from me. Arnold From rc-owner Fri Feb 14 12:32:21 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 12:24:57 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2735>; Fri, 14 Feb 1992 13:24:24 -0500 To: rc@archone.tamu.edu Subject: Re: configuration parameters In-reply-to: brendan's message of Fri, 14 Feb 92 12:41:25 -0500. <199202141741.AA12880@lisa.cs.widener.edu> Date: Fri, 14 Feb 1992 12:24:12 -0600 From: Chris Siebenmann Message-Id: <92Feb14.132424est.2735@hawkwind.utcs.toronto.edu> Can someone describe the GNU configure tool? Does it fall down on strange machines? Does it force you to answer lots of chatty questions? - cks From rc-owner Fri Feb 14 12:49:13 1992 Received: from relay1.UU.NET ([137.39.1.5]) by archone.tamu.edu with SMTP id <45334>; Fri, 14 Feb 1992 12:42:21 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA12228; Fri, 14 Feb 92 13:42:16 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 134159.26734; Fri, 14 Feb 1992 13:41:59 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa03656; Fri, 14 Feb 92 13:24:47 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: byron@archone.tamu.edu, rc@archone.tamu.edu Subject: Re: configuration parameters Date: Fri, 14 Feb 1992 12:25:06 -0600 Message-Id: <9202141325.aa10591@ceres.srg.af.mil> I'd like to agree with Chris on this and disagree with who ever suggested using imake. Having the configuration parameters in the make file, as they are now, works beautifully. As matters stand I copy "Makefile" to "makefile" edit the configuration options in that and go. I never even have to touch any of the original files (aside from applying patches from Byron ;-) ). This is utterly painless and shows an absolutely incredible level of portability. Having ported more packages than I care to count to various machines, rc is probably the cleanest. Most packages get checked into RCS the minute they're unbundled so we can track the changes necessary just to get them running, not so with rc! As to Imake... While the concept is probably OK the execution generally stinks. I've never seen it work right yet. Please don't inflict it on us! Tom From rc-owner Fri Feb 14 13:19:00 1992 Received: from relay1.UU.NET ([137.39.1.5]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 13:13:50 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA22985; Fri, 14 Feb 92 14:13:40 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 141244.9674; Fri, 14 Feb 1992 14:12:44 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa03979; Fri, 14 Feb 92 14:01:12 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: cks@hawkwind.utcs.toronto.edu, rc@archone.tamu.edu Subject: Re: configuration parameters Date: Fri, 14 Feb 1992 13:01:30 -0600 Message-Id: <9202141401.aa10658@ceres.srg.af.mil> >> Can someone describe the GNU configure tool? Does it fall down on >> strange machines? Does it force you to answer lots of chatty questions? >> >> - cks I've had many problems porting "Auto-configuring" GNU (etc.) stuff to SCO Unix. To the best of my knowledge their configure stuff is very similar (if not identical to) Larry Wall's which also has problems with SCO. Admittedly SCO Unix is a bastard cross between a bull bitch and a window shutter, (don't ask me what that means it's just something my father used to say) and has various bugs, mis-features and down right stupidity built in for our enjoyment, but there's a lot of it out here in the real world. For example... most auto-config packages deduce that SCO has a working POSIX rename function. BZZZZT! Just try to use it on a NFS mounted file system and watch the fun. Hand editing make files usually works much better unless the number of configuration options is about three or four times what rc has now. Tom From rc-owner Fri Feb 14 14:35:11 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 14:27:16 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA28059; Fri, 14 Feb 92 21:27:00 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA05683; Fri, 14 Feb 92 21:26:59 +0100 Date: Fri, 14 Feb 1992 14:26:59 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202142026.AA05683@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: to imake or not to imake I don't want to start any religious wars, but imake -once set up correctly- usually shortens installation procedures to "imkmf; make install", especially if the sources are as portable as rc is. Before stating that imake doesn't work, one should have a look at imake coming from Wisconsin Regional Primate Research Center ( the original ) or the X11R5 thing. For those who are not running imake, a Makefile can be included in the distribution, ready to be hacked manually. Of course, it is not worth installing imake just to configure rc. Malte. From rc-owner Fri Feb 14 14:57:05 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 14:52:39 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Fri, 14 Feb 1992 15:52:12 -0500 To: malte@techfak.uni-bielefeld.de cc: rc@archone.tamu.edu Subject: Re: to imake or not to imake In-reply-to: Your message of "Fri, 14 Feb 92 15:26:59 EST." <9202142026.AA05683@dahlie.techfak.uni-bielefeld.de> Date: Fri, 14 Feb 1992 14:52:05 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Feb14.155212est.2538@groucho.cs.psu.edu> | I don't want to start any religious wars, but imake -once set up correctly- | usually shortens installation procedures to "imkmf; make install", especially | if the sources are as portable as rc is. But setting up imake is much harder than just setting up rc. And it is different for every package! One directory full of imake config files for InterViews, one for X11, one for Modula-3, etc, etc, etc. And even when you have all that stuff straightened out, you gain nothing over what we have now: editing a Makefile to comment out a couple of defines verses editing an Imakefile to comment out a couple of defines... where's the win? Keep simple things simple, please! From rc-owner Fri Feb 14 15:29:56 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 15:22:01 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2736>; Fri, 14 Feb 1992 16:21:34 -0500 To: rc@archone.tamu.edu Subject: Re: to imake or not to imake In-reply-to: malte's message of Fri, 14 Feb 92 15:26:59 -0500. <9202142026.AA05683@dahlie.techfak.uni-bielefeld.de> Date: Fri, 14 Feb 1992 15:21:32 -0600 From: Chris Siebenmann Message-Id: <92Feb14.162134est.2736@hawkwind.utcs.toronto.edu> Unless I am badly mistaken, Imake's (current) options do not answer much of rc's configuration questions, if any. I don't want to install another version of imake, or have to patch my Imake configuration files, just to compile rc. - cks From rc-owner Fri Feb 14 15:40:15 1992 Received: from rt.sunquest.com ([192.12.52.50]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 15:35:54 -0600 Received: by rt.sunquest.com (AIX 2.1 2/4.03) id AA03158; Fri, 14 Feb 92 14:37:45 MST Date: Fri, 14 Feb 1992 15:37:45 -0600 From: jew@rt.sunquest.com Message-Id: <9202142137.AA03158@rt.sunquest.com> To: cks@hawkwind.utcs.toronto.edu Cc: rc@archone.tamu.edu In-Reply-To: Chris Siebenmann's message of Fri, 14 Feb 1992 15:21:32 -0600 <92Feb14.162134est.2736@hawkwind.utcs.toronto.edu> Subject: to imake or not to imake On a similar note to the imake question, I haven't compiled the latest version of rc because I didn't want to go find unproto, download it, compile it, run it/or get the patch to make it work from the author. I liked the awk scripts from before. Do they work in place of unproto? (This is for an IBM PC/RT running AIX 2.2.1) From rc-owner Fri Feb 14 17:31:34 1992 Received: from Princeton.EDU ([128.112.128.1]) by archone.tamu.edu with SMTP id <45338>; Fri, 14 Feb 1992 17:21:03 -0600 Received: from and.Princeton.EDU by Princeton.EDU (5.65b/2.85/princeton) id AA27372; Fri, 14 Feb 92 18:20:43 -0500 Received: by math.princeton.edu (4.0/1.110) id AA12650; Fri, 14 Feb 92 18:20:40 EST Date: Fri, 14 Feb 1992 17:20:40 -0600 Message-Id: <9202142320.AA12650@math.princeton.edu> From: rjc@math.Princeton.EDU To: rc@archone.tamu.edu Subject: Re: configuration parameters If we don't go with the config.h file, how about making the .o files dependent on the Makefile itself? When trying to get rc up and running, I'll be tweaking the Makefile switches and adjusting the source and I'll forget to rm *.o before re-making, yielding a bizarre combination of old and new object code in the final executeable. You can imagine how often I mumble to myself, ``But wait, I thought I fixed that in the Makefile...'' -- Raymond (not named after `rc') Chen From rc-owner Fri Feb 14 18:15:46 1992 Received: from relay1.UU.NET ([137.39.1.5]) by archone.tamu.edu with SMTP id <45329>; Fri, 14 Feb 1992 18:12:35 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25373; Fri, 14 Feb 92 19:12:21 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 191105.19232; Fri, 14 Feb 1992 19:11:05 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa06066; Fri, 14 Feb 92 18:50:10 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@archone.tamu.edu Subject: Some SCO hints and comments Date: Fri, 14 Feb 1992 17:50:27 -0600 Message-Id: <9202141850.aa10992@ceres.srg.af.mil> This is a horribly long and multi-topic message for the benefit of folks who use or want to use RC under SCO Unix. Apologies to everyone else. The lines of dashes are cut marks for various pieces. ------------------------------------------------------------------------------ Below are diffs for the configuration settings I use for SCO Unix. Note that I use GNU readline, you may wish to use something else. ------------------------------------------------------------------------------ 24c24 < #SVSIGS = -DSVSIGS --- > SVSIGS = -DSVSIGS 27c27 < #DEVFD = -DDEVFD --- > DEVFD = -DDEVFD 31c31 < #NOLIMITS = -DNOLIMITS --- > NOLIMITS = -DNOLIMITS 35c35 < #NOSIGCLD = -DNOSIGCLD --- > NOSIGCLD = -DNOSIGCLD 39c39 < #READLINE = -DREADLINE --- > READLINE = -DREADLINE 49,50c49,50 < #NOEXECVE = -DNOEXECVE < #EXECVE = execve.o --- > NOEXECVE = -DNOEXECVE > EXECVE = execve.o 60c60 < #DEFAULTINTERP = -DDEFAULTINTERP=\"/bin/sh\" --- > DEFAULTINTERP = -DDEFAULTINTERP=\"/bin/sh\" 66c66 < #PROTECT_ENV = -DPROTECT_ENV --- > PROTECT_ENV = -DPROTECT_ENV 79c79,80 < YACC=yacc --- > #YACC=yacc > YACC=bison -y 95c96,97 < $(CC) -o $@ $(OBJS) --- > $(CC) -o $@ $(OBJS) -lreadline -ltermcap > # $(CC) -o $@ $(OBJS) 104a107,110 > > strip: > strip rc > mcs -d rc ------------------------------------------------------------------------------ # Some functions to increase the speed of RC scripts under SCO Unix. # These can make a marked difference if you put them in $home/.rcrc # This mollifies variable setting scripts. It won't deal with the KSH # and BASH form "export VARIABLE=value" but it's never been a problem # for me. fn export {} # These are MUCH more efficient than SCO Unix's shell scripts fn true { return 0 } fn false { return 255 } # You may want to use GNU test if you can but this is faster than # the existing shell script fn test { /bin/sh -c 'test '^$^* } ------------------------------------------------------------------------------ # If you use RC the system C compiler gets hiccups when run by make. # This seems to be because it generates a command line using -ce which is # not getopt compatible. You can either try editing the make binary or # put this script in your path as cc so it is found before /bin/cc. # This is a hack that keeps the compiler from segment faulting. exec /bin/cc $* ------------------------------------------------------------------------------ Header files... sigh. SCO has a perenial problem with header files. There is always something else that needs to be fixed. The system C header files in /usr/include and /usr/include/sys, the C++ header files (SCO Canada, ne-HCR) in /usr/include/CC and /usr/include/CC/sys and even the gcc header files in /usr/local/lib/gcc-include seem infected. I won't even try to list all of the problems here. The ones most likely to affect RC are /usr/include/signal.h /usr/include/sys/signal.h /usr/include/sys/types.h and /usr/local/lib/gcc-include/stdarg.h. (Unfortunately mine have been fixed for quite a while and I don't recall what the exact problems were.) SCO has recent updates for this stuff and if you've got a problem compiling BUG THE HELL OUTA 'EM. They need to know that we won't accept shoddy quality in the development environment. The problem with gcc's stdarg.h is the trailing underscore on "_VA_LIST" take it off and the rest works fine. From rc-owner Fri Feb 14 22:12:19 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45338>; Fri, 14 Feb 1992 22:08:39 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Fri, 14 Feb 1992 23:08:16 -0500 To: rc@archone.tamu.edu Subject: signals and suchlike Date: Fri, 14 Feb 1992 22:08:13 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Feb14.230816est.2538@groucho.cs.psu.edu> Using rc-1.3b, some questions about signals... ; whatis sigint # implicitly ignored, right? sigint not found # so why not say so? ; fn sigint {} # set to ignored ; whatis sigint # not the same? fn sigint {} # hmm The man page says that signals are reset to their default values in subshells. CHANGES says that ignored signals stay ignored. It seems like the man page is correct, though: ; cat x #!/bin/rc whatis sigint sleep 100000 ; hup x # hup runs x in the process group of the tty, so it # receives signals, but also sets sigint to sig_ign. sigint not found ; ^C # this kills x. An analogous /bin/sh script behaves as expected. From rc-owner Fri Feb 14 22:43:40 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45338>; Fri, 14 Feb 1992 22:40:25 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2736>; Fri, 14 Feb 1992 23:40:01 -0500 To: rc@archone.tamu.edu Subject: Re: signals and suchlike In-reply-to: schwartz's message of Fri, 14 Feb 92 23:08:13 -0500. <92Feb14.230816est.2538@groucho.cs.psu.edu> Date: Fri, 14 Feb 1992 22:39:47 -0600 From: Chris Siebenmann Message-Id: <92Feb14.234001est.2736@hawkwind.utcs.toronto.edu> The manual page is correct; ignored signals and default signals are passed to children as-is, while signals that are caught to a function are reset to default in children. This is slightly opaque in the manual, but not very much (at least the signal section; perhaps there's wording elsewhere). - cks From rc-owner Fri Feb 14 23:04:34 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45338>; Fri, 14 Feb 1992 23:01:32 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2743>; Sat, 15 Feb 1992 00:01:03 -0500 To: rc@archone.tamu.edu Subject: Re: signals and suchlike Date: Fri, 14 Feb 1992 23:00:57 -0600 From: Chris Siebenmann Message-Id: <92Feb15.000103est.2743@hawkwind.utcs.toronto.edu> A bug in signal handling: rc unconditionally ignores a SIG_IGN'd SIGINT, even if it's running a shell. It should not; if SIGINT is ignored on entry to a shell script, rc should not change this. Only when it's interactive is it entitled to play around with signals in that way. - cks From rc-owner Sat Feb 15 08:57:43 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45329>; Sat, 15 Feb 1992 08:52:03 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA00410; Sat, 15 Feb 92 15:51:37 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA06029; Sat, 15 Feb 92 15:51:36 +0100 Date: Sat, 15 Feb 1992 08:51:36 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202151451.AA06029@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: Re: AIX In-Reply-To: Mail from 'Byron Rakitzis ' dated: Fri, 14 Feb 1992 15:53:34 -0600 It seems imake is not welcome at all, so here is another suggestion how to configure rc: What about writing header files including os dependend defines? One will have to link the correct os header to say os.h before compiling. Changes to Makefile will be reduced to installation parameters. For those cases where no suitable header is provided, there should be a summary of defines somewhere. New headers should be collected somewhere. Malte. ps: AIX compilers define "_AIX". From rc-owner Sat Feb 15 09:01:30 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45330>; Sat, 15 Feb 1992 08:57:53 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA00414; Sat, 15 Feb 92 15:54:15 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA06039; Sat, 15 Feb 92 15:54:13 +0100 Date: Sat, 15 Feb 1992 08:54:13 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202151454.AA06039@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: multiple copies of mail In the last few days, I get multiple copies of the same mail. Is this a global effect ? Malte. From rc-owner Sat Feb 15 20:15:13 1992 Received: from relay2.UU.NET ([137.39.1.7]) by archone.tamu.edu with SMTP id <45329>; Sat, 15 Feb 1992 20:11:14 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04388; Sat, 15 Feb 92 21:11:07 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 211034.1127; Sat, 15 Feb 1992 21:10:34 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa15429; Sat, 15 Feb 92 20:50:37 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: cks@hawkwind.utcs.toronto.edu, rc@archone.tamu.edu Subject: Re: signals and suchlike Date: Sat, 15 Feb 1992 19:50:54 -0600 Message-Id: <9202152050.aa11758@ceres.srg.af.mil> There are a couple of problems with signal handling that Byron is working on at the moment and will undoubtedly fix before 1.3 gets out of beta. I found that SIGINT seemed to be ignored but would work if sent several time in quick succesion (by tap-tap-tapping ^C or whatever you have it set to.) Tom From rc-owner Sat Feb 15 22:01:24 1992 Received: from frey.newcastle.edu.au ([134.148.236.1]) by archone.tamu.edu with SMTP id <45329>; Sat, 15 Feb 1992 21:59:16 -0600 Received: by frey.newcastle.edu.au id AA24978 (5.65c/IDA-1.4.4 for rc@archone.tamu.edu); Sun, 16 Feb 1992 14:58:47 +1100 From: Alan Hargreaves Message-Id: <199202160358.AA24978@frey.newcastle.edu.au> Subject: Re: configuration parameters To: rc@archone.tamu.edu Date: Sun, 16 Feb 1992 13:58:46 -0600 X-Mailer: ELM [version 2.3 PL11] > Date: Fri, 14 Feb 1992 17:20:40 -0600 > From: rjc@math.Princeton.EDU > Subject: Re: configuration parameters > > If we don't go with the config.h file, how about making the .o files > dependent on the Makefile itself? When trying to get rc up and running, > I'll be tweaking the Makefile switches and adjusting the source and > I'll forget to rm *.o before re-making, yielding a bizarre combination > of old and new object code in the final executeable. You can imagine > how often I mumble to myself, ``But wait, I thought I fixed that > in the Makefile...'' simpler idea, why not have config.h depend on Makefile and have make build config.h? We have a few locally written packages here that do it that way. alan. -- Alan Hargreaves (VK2MGL) alan@frey.newcastle.edu.au, Uni of Newcastle, UCS. Ph: +61 49 215 512 Fax: +61 49 687 472 ICBM: 32 53 44.6 S / 151 41 52.6 E Software Bloat - Any UNIX(tm) after Version 7. (Sm@cerberus.bhpese.oz.au) From rc-owner Sun Feb 16 21:50:30 1992 Received: from lisa.cs.widener.edu ([147.31.254.23]) by archone.tamu.edu with SMTP id <45329>; Sun, 16 Feb 1992 21:45:55 -0600 Received: by lisa.cs.widener.edu id AA05530 (5.65c/Widener-4.1 for rc@archone.tamu.edu); Sun, 16 Feb 1992 22:45:44 -0500 Date: Sun, 16 Feb 1992 21:45:44 -0600 From: Brendan Kehoe Message-Id: <199202170345.AA05530@lisa.cs.widener.edu> To: rc@archone.tamu.edu Subject: TeXing with rc I just threw this together, and thought it was sorta neat: fn dotex { eval ('tex ' '&& dvijep ' '&& lpr -Pdvi -h ')^$*^(.tex .dvi .dvi-jep) } It'll tex a file, convert it into something our LaserJet can handle, then print it out, too. :-) Brendan P.S. I couldn't get around using the .tex and .dvi extensions; they're not really necessary, though. (() () .dvi-jep) didn't cut it. Any suggestions? From rc-owner Mon Feb 17 09:41:00 1992 Received: from rt.sunquest.com ([192.12.52.50]) by archone.tamu.edu with SMTP id <45329>; Mon, 17 Feb 1992 09:33:26 -0600 Received: by rt.sunquest.com (AIX 2.1 2/4.03) id AA06686; Mon, 17 Feb 92 08:35:10 MST Date: Mon, 17 Feb 1992 09:35:10 -0600 From: jew@rt.sunquest.com Message-Id: <9202171535.AA06686@rt.sunquest.com> To: alan@frey.newcastle.edu.au Cc: rc@archone.tamu.edu In-Reply-To: Alan Hargreaves's message of Sun, 16 Feb 1992 13:58:46 -0600 <199202160358.AA24978@frey.newcastle.edu.au> Subject: configuration parameters I downloaded and compiled the latest version of kermit over the weekend. It had a seperate set of options for each platform, for instance to compile it on this old wheezer, I type: make aixrt or somesuch. Is that a horrible solution? From rc-owner Mon Feb 17 20:20:46 1992 Received: from Princeton.EDU ([128.112.128.1]) by archone.tamu.edu with SMTP id <45331>; Mon, 17 Feb 1992 20:13:12 -0600 Received: from and.Princeton.EDU by Princeton.EDU (5.65b/2.85/princeton) id AA27826; Mon, 17 Feb 92 21:12:55 -0500 Received: by math.princeton.edu (4.0/1.110) id AA10506; Mon, 17 Feb 92 21:12:52 EST Date: Mon, 17 Feb 1992 20:12:52 -0600 Message-Id: <9202180212.AA10506@math.princeton.edu> From: rjc@math.Princeton.EDU To: rc@archone.tamu.edu Subject: Bug in Simmy's readline replacement (with patch) This one took me two days to track down. edit/editline.c, function insert_string: Change if ((el_end + len) > el_length) to if ((el_end + len + 1) > el_length) or more efficiently, if ((el_end + len) >= el_length) Simmy forgot to count the trailing 0 that terminates a string. Without this, we end up storing a 0 past the end of our allocated block, stomping on the malloc arena, and causing weird crashes in weird places at unspecified points in the future. (Sorry, no context diff since I had to hack up other stuff to get rc to run on my bizarre box that doesn't deserve the name UNIX.) -- Raymond ``What a ripoff. I bust my butt day in and day out...''[7f01] Chen (Only Brendan will get the quote ref.) From rc-owner Tue Feb 25 02:59:20 1992 Received: from po5.andrew.cmu.edu ([128.2.10.105]) by archone.tamu.edu with SMTP id <45329>; Tue, 25 Feb 1992 02:37:20 -0600 Received: by po5.andrew.cmu.edu (5.54/3.15) id for rc@archone.tamu.edu; Tue, 25 Feb 92 03:36:59 EST Received: via switchmail; Tue, 25 Feb 1992 03:36:54 -0500 (EST) Received: from sucre.mdg.andrew.cmu.edu via qmail ID ; Tue, 25 Feb 1992 03:36:27 -0500 (EST) Date: Tue, 25 Feb 1992 02:36:21 -0600 From: "Julian L. Ho" Subject: history on AFS To: rc@archone.tamu.edu Message-Id: <699006981.4235.0@sucre.mdg.andrew.cmu.edu> Sorry if this isn't the sort of thing you want in your mailbox. Here is what I've been using to keep my history file updated in spite of AFS... -J # AFS holds a complete history, always. This is atomic on a per machine, # per login basis. Avoid logging out more than once, at the same time. # history file for this shell and all its children # put on the local hard drive (hopefully O_APPEND works there) history = /tmp/. ^ $USER ^ _history_ ^ $pid # build history file (or turn off all history processing) if (cp $home/.history $history) { oldhistsiz = `{ wc -l $history } oldhistsiz = $oldhistsiz(1) } else history = () # clean up machine local history # add to sigexit fn history { if (~ $history ()) return if (~ $oldhistsiz ()) oldhistsiz = `{ wc -l $history } L = `{ expr $oldhistsiz(1) + 1 } \ sed -n $L ^ ',$p' $history >>$home/.history && rm -f $history } From rc-owner Wed Feb 26 06:09:20 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45329>; Wed, 26 Feb 1992 06:01:56 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA01382; Wed, 26 Feb 92 13:01:25 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA27103; Wed, 26 Feb 92 11:34:13 +0100 Date: Wed, 26 Feb 1992 04:34:13 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202261034.AA27103@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: Mailserver for this list running wild Sorry to disturb you all, but Who ever is responsible for that, LISTEN : I'm really getting annoyed by receiving outdated mail that could not be delivered , and which I haven't even sent. All these mails deal with rc related topics and were received via ARCHONE.TAMU.EDU. The mailer is Postmaster@hera.cai.com and its maintainers should be reachable as zort.ns.psi.net but don't answer. Stop it please. Its not fun getting upt to 3 trash mails per hour. Malte. From rc-owner Wed Feb 26 13:45:47 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45330>; Wed, 26 Feb 1992 13:39:40 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA03262; Wed, 26 Feb 92 20:38:41 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA00796; Wed, 26 Feb 92 20:38:39 +0100 Date: Wed, 26 Feb 1992 13:38:39 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9202261938.AA00796@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: strangeness with big variables under ultrix 4.1 I have just dicovered a strangeness running rc1.3b on a decstation ultrix 4.1: allman = `{ man -nrsp '.*' } This assigns allman the names of all manpages available, in short, a very large value (>250KB). After doing so, any external command issued, with or without arguments, gives the error message ': Arg list too long' so I can't find out what happens. Is this a bug in rc or ultrix ? Malte. _______________________________________________________________________________ malte@techfak.uni-bielefeld.de send mail reply to: Universitaet Bielefeld, Technische Fakultaet z. Hd. Malte Uhl Postfach 8640 4800 Bielefeld 1 From rc-owner Wed Feb 26 13:56:54 1992 Received: from pineapple.bbn.com ([128.11.0.16]) by archone.tamu.edu with SMTP id <45331>; Wed, 26 Feb 1992 13:52:31 -0600 Received: from litchi.bbn.com by pineapple.bbn.com id ; Wed, 26 Feb 92 14:52:00 -0500 From: Rich Salz Received: by litchi.bbn.com id ; Wed, 26 Feb 92 14:51:55 EST Date: Wed, 26 Feb 1992 13:51:55 -0600 Message-Id: <9202261951.AA15500@litchi.bbn.com> To: malte@techfak.uni-bielefeld.de, rc@archone.tamu.edu Subject: Re: strangeness with big variables under ultrix 4.1 Rc puts everything in the environment and most systems have a limit on the size of the environment... From rc-owner Wed Feb 26 14:24:30 1992 Received: by archone.tamu.edu id <45330>; Wed, 26 Feb 1992 14:20:44 -0600 From: Byron Rakitzis To: rc Subject: bad mail Message-Id: <92Feb26.142044cst.45330@archone.tamu.edu> Date: Wed, 26 Feb 1992 14:20:34 -0600 Anyone who is getting bad mail, please let me know immediately and send me a full copy of the header you are getting. I just want to be certain that archone's mailer is not misbehaving; bounced mail should be going to rc-owner@archone.tamu.edu (that's me) *not* rc@archone.tamu.edu. From rc-owner Wed Feb 26 15:21:36 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45332>; Wed, 26 Feb 1992 15:09:52 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2718>; Wed, 26 Feb 1992 16:08:35 -0500 To: rc@archone.tamu.edu Subject: Re: strangeness with big variables under ultrix 4.1 In-reply-to: malte's message of Wed, 26 Feb 92 14:38:39 -0500. <9202261938.AA00796@dahlie.techfak.uni-bielefeld.de> Date: Wed, 26 Feb 1992 15:08:30 -0600 From: Chris Siebenmann Message-Id: <92Feb26.160835est.2718@hawkwind.utcs.toronto.edu> 'Arg list too long' is actually 'Arg list or environment too long', because most Unixes have a limit on the total argument list + environment size that execve() will handle. Ultrix just has a somewhat lower limit than other systems (I think SunOS has really cranked it up, for example). - cks From rc-owner Wed Feb 26 16:02:04 1992 Received: from yonge.csri.toronto.edu ([128.100.1.2]) by archone.tamu.edu with SMTP id <45332>; Wed, 26 Feb 1992 15:57:06 -0600 Received: by yonge.csri.toronto.edu with UUCP id <223>; Wed, 26 Feb 1992 16:56:12 -0500 Received: by redvax (4.0/SMI-4.0) id AA08885; Wed, 26 Feb 92 16:56:06 EST Date: Wed, 26 Feb 1992 15:56:06 -0600 From: hugh@redvax.uucp ("D. Hugh Redelmeier") Message-Id: <9202262156.AA08885@redvax> To: cks@hawkwind.utcs.toronto.edu, rc@archone.tamu.edu Subject: Re: strangeness with big variables under ultrix 4.1 | 'Arg list too long' is actually 'Arg list or environment too long', | because most Unixes have a limit on the total argument list + environment | size that execve() will handle. Well, here is a practical reason to not have every rc variable exported. I have argued this on aesthetic grounds before. Hugh Redelmeier {utcsri, uunet!attcan, utzoo, scocan}!redvax!hugh When all else fails: hugh@csri.toronto.edu +1 416 482-8253 From rc-owner Wed Feb 26 16:42:53 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45333>; Wed, 26 Feb 1992 16:35:09 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2725>; Wed, 26 Feb 1992 17:33:23 -0500 To: rc@archone.tamu.edu Subject: Re: strangeness with big variables under ultrix 4.1 In-reply-to: hugh's message of Wed, 26 Feb 92 16:56:06 -0500. <9202262156.AA08885@redvax> Date: Wed, 26 Feb 1992 16:33:20 -0600 From: Chris Siebenmann Message-Id: <92Feb26.173323est.2725@hawkwind.utcs.toronto.edu> It would be nice to have some sort of 'local' declaration for variables, such that they aren't handed to exec()ed programs, but I don't think it should ever be the default. Almost all of my variables are ones I want to export. - cks From rc-owner Wed Feb 26 19:38:14 1992 Received: from relay1.UU.NET ([137.39.1.5]) by archone.tamu.edu with SMTP id <45333>; Wed, 26 Feb 1992 19:32:41 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28146; Wed, 26 Feb 92 15:16:05 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 151022.27908; Wed, 26 Feb 1992 15:10:22 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa22214; Wed, 26 Feb 92 14:46:48 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@archone.tamu.edu Subject: Useful rc idiom Date: Wed, 26 Feb 1992 13:47:29 -0600 Message-Id: <9202261447.aa26127@ceres.srg.af.mil> Please excuse me if I'm being redundant, I don't remember where I first saw this or discovered it, but it seems like something that should written in large letters. When writing functions in rc a useful idiom for local variables (what C calls auto) is something like this... fn func_name { xyz=() abc=$1 here=`{pwd} { # Body of the the function which can be called recursively with each # level getting it's own copy of the variables files, dirs and here. # The arguments of course are still in $1 $2 .... }} This rc stuff sure is nice, isn't it. ;-) Tom BTW - if you don't do this and reuse variables inside a recursive function it can be very hard to track down whats going on. ;-) From rc-owner Wed Feb 26 19:41:58 1992 Received: from eros.uknet.ac.uk ([192.91.199.2]) by archone.tamu.edu with SMTP id <45331>; Wed, 26 Feb 1992 19:38:26 -0600 Received: from ibmpcug.co.uk by eros.uknet.ac.uk with UUCP id <427-0@eros.uknet.ac.uk>; Thu, 27 Feb 1992 01:32:09 +0000 Received: by ibmpcug.co.uk (smail2.5) id AA02241; 27 Feb 92 01:07:25 GMT (Thu) X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. In-Reply-To: <9202261951.AA15500@litchi.bbn.com> Organization: The IBM PC User Group, UK. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: rc@archone.tamu.edu Subject: Re: strangeness with big variables under ultrix 4.1 Message-Id: <9202270107.AA02236@ibmpcug.co.uk> Date: Wed, 26 Feb 1992 19:07:24 -0600 From: Matthew Farwell In article <9202261951.AA15500@litchi.bbn.com> you write: >Rc puts everything in the environment and most systems have a limit >on the size of the environment... Maybe someone should write an xargs-like program for the environment, :-) Dylan. -- If you can waggle it and he can feel it, you have a signalling system. From rc-owner Thu Mar 5 23:23:41 1992 Received: from relay1.UU.NET ([137.39.1.5]) by archone.tamu.edu with SMTP id <45332>; Thu, 5 Mar 1992 23:07:07 -0600 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10560; Thu, 5 Mar 92 16:23:07 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 162141.6936; Thu, 5 Mar 1992 16:21:41 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa23246; Thu, 5 Mar 92 15:53:38 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@archone.tamu.edu Subject: Minor patch for READLINE users Date: Thu, 5 Mar 1992 14:53:47 -0600 Message-Id: <9203051553.aa19560@ceres.srg.af.mil> *** var.bak Thu Mar 5 15:49:08 1992 --- var.c Thu Mar 5 15:49:36 1992 *************** *** 19,25 **** new->def = newdef; new->extdef = NULL; #ifdef READLINE /* need to reset readline() every time TERM or TERMCAP changes */ ! if (interactive && streq(name, "TERM") || streq(name, "TERMCAP")) { extern void rl_reset_terminal(char *); rl_reset_terminal(NULL); } --- 19,25 ---- new->def = newdef; new->extdef = NULL; #ifdef READLINE /* need to reset readline() every time TERM or TERMCAP changes */ ! if (interactive && (streq(name, "TERM") || streq(name, "TERMCAP"))) { extern void rl_reset_terminal(char *); rl_reset_terminal(NULL); } From rc-owner Wed Mar 11 01:25:14 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45332>; Wed, 11 Mar 1992 01:20:43 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2541>; Wed, 11 Mar 1992 02:19:30 -0500 To: rc@archone.tamu.edu Subject: comments, newlines Date: Wed, 11 Mar 1992 01:19:18 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Mar11.021930est.2541@groucho.cs.psu.edu> Consider this rc script: x=(1 \ # 2 \ 3) Using Byron's rc, this gets a syntax error. Does Tom Duff's rc behave similarly? This doesn't seem like useful behavior to me: it makes it too hard to use comments in a natural way. From rc-owner Thu Mar 12 04:16:26 1992 Received: from uucp-gw-1.pa.dec.com ([16.1.0.18]) by archone.tamu.edu with SMTP id <45334>; Thu, 12 Mar 1992 04:07:12 -0600 Received: by uucp-gw-1.pa.dec.com; id AA01829; Wed, 11 Mar 92 23:19:22 -0800 Received: from utopia.adobe.com by adobe.com (4.1/SMI-4.1) id AA18584; Wed, 11 Mar 92 09:28:53 PST Received: by utopia.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA04643; Wed, 11 Mar 92 09:27:00 PST Date: Wed, 11 Mar 1992 11:27:00 -0600 From: haahr@adobe.com Message-Id: <9203111727.AA04643@utopia.adobe.com> Received: by NeXT Mailer (1.63) To: schwartz@groucho.cs.psu.edu Subject: Re: comments, newlines Cc: rc mailing list the reason that x=(1 \ # 2 \ 3) doesn't work is straightforward interpretation of rc's rules for continued lines and comments. the first \+newline sequence results in the parser seeing x=(1 # 2 \ 3) which seems reasonable. now the question becomes, ``are backslash-newline sequences in comments ignored or treated as continuation sequences?'' rc currently implements comments by ignoring *everything* until the end of line. the simplicity of this rule argues for not changing it. two further comments: i don't find the ability to insert a comment in the middle of a sequence of lines continued with \ important i have no idea what td's rc does for this From rc-owner Thu Mar 12 06:00:57 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45336>; Thu, 12 Mar 1992 05:56:41 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA13374; Thu, 12 Mar 92 12:56:13 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA12326; Thu, 12 Mar 92 12:56:12 +0100 Date: Thu, 12 Mar 1992 05:56:12 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9203121156.AA12326@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: talking about syntax I'd like to suggest an improvement to rc's manual page. 1) commands may be preceeded by local variable definitions 2) simple commands can be grouped by '{' and '}' 3) backquote substitution looks like `{ complex_command } or `simple_command The manpages also says that amongst others '`' and '{' are special characters to rc. Simple minds may come to the conclusion that echo ` x=list { echo $x } is valid rc syntax. My suggestion is not to enumerate special charaters but special tokens, one of them being '`{'. Another suggestion is to change the parser in a way that '~' is only special if it is a command, just like '\' is only special if being followed by a newline charater. This would make it possible to specify negated character classes in pattern matching in the same way as other shells do, thus making transition from [c]sh to rc a little easier. It will also allow a simple hack to use ~ as a substitute for $HOME. Malte. From rc-owner Fri Mar 13 03:06:01 1992 Received: from watmath.waterloo.edu ([129.97.140.144]) by archone.tamu.edu with SMTP id <45332>; Fri, 13 Mar 1992 03:02:55 -0600 Received: from xenitec.uucp by watmath.waterloo.edu with uucp id ; Fri, 13 Mar 92 04:02:00 -0500 Received: from golem by xenitec.xenitec.on.ca id aa04085; 12 Mar 92 18:09 EST Received: by golem.uucp (/\==/\ Smail3.1.24.1 #24.15) id ; Thu, 12 Mar 1992 17:05 -0500 To: haahr@adobe.com Cc: schwartz@groucho.cs.psu.edu, rc@archone.tamu.edu Subject: Re: comments, newlines In-Reply-To: Your message of "Wed, 11 Mar 92 12:27:00 EST." <9203111727.AA04643@utopia.adobe.com> Date: Thu, 12 Mar 1992 16:05:48 -0600 Message-Id: <5714.700437948@golem> From: "David J. Fiander" >From: haahr@adobe.com >lines and comments. the first \+newline sequence results in the parser >seeing > x=(1 # 2 \ > 3) >which seems reasonable. now the question becomes, ``are backslash-newline >sequences in comments ignored or treated as continuation sequences?'' rc >currently implements comments by ignoring *everything* until the end of >line. the simplicity of this rule argues for not changing it. The way in which the rule is interpreted doesn't matter. If \+nl is interpreted even in comments, then the shell will see x=(1 # 2 3) and ignore everything after the '#' and _still_ complain about a syntax error. - David From rc-owner Fri Mar 13 04:27:13 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <45334>; Fri, 13 Mar 1992 04:24:45 -0600 Received: by doolittle.vetsci.su.oz.au id <49223>; Fri, 13 Mar 1992 20:24:10 +1000 From: John (I've got some bad news for you, sunshine) Mackin Date: Fri, 13 Mar 1992 04:14:22 -0600 To: The rc Mailing List Subject: Re: comments, newlines In-Reply-To: <5714.700437948@golem> Message-ID: <199203132014.5018.rc.bagel@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I agree with Paul. The rule doesn't need to be changed. In fact, I think it definitely should NOT be, since I think it makes scripts significantly harder to read if comments are inserted inside continued commands. But: The way in which the rule is interpreted doesn't matter. If \+nl is interpreted even in comments, then the shell will see x=(1 # 2 3) This doesn't make sense. The rule is, ignore everything between # and newline, INCLUDING THE #. I mean, if you go echo foo # bar you get "foo", not "foo #". So if backslash were to be interpreted at the end of a comment, that wouldn't happen, and it would all work. And now for my real reason for sending this: there is one thing about # that I have never liked. I have complained privately about this (long ago), but Byron didn't agree with me: so let's see if we can get some public support for _this_ idea. I claim that # should only be seen as a comment introducer if it is preceded by whitespace or at the start of the line. So if you do echo foo#bar you should, in my view, get "foo#bar". You do in sh. You don't in rc: Byron thinks # should introduce a comment even if it is in the middle of a word. I think this is plainly wrong. Opinions? OK, John. From rc-owner Fri Mar 13 16:48:19 1992 Received: from plg.waterloo.edu ([129.97.140.10]) by archone.tamu.edu with SMTP id <45336>; Fri, 13 Mar 1992 16:45:01 -0600 Received: by plg.waterloo.edu id <49339>; Fri, 13 Mar 1992 17:44:41 -0500 From: Dave Mason To: The rc Mailing List In-reply-to: John (I've got some bad news for you, sunshine) Mackin's message of Fri, 13 Mar 1992 05:14:22 -0500 <199203132014.5018.rc.bagel@vetsci.su.oz.au> Subject: RE: comments, newlines Message-Id: <92Mar13.174441est.49339@plg.waterloo.edu> Date: Fri, 13 Mar 1992 16:44:35 -0600 > From: John (I've got some bad news for you, sunshine) Mackin > Date: Fri, 13 Mar 1992 05:14:22 -0500 > I claim that # should only be seen as a comment introducer if it is > preceded by whitespace or at the start of the line. So if you do > > echo foo#bar > > you should, in my view, get "foo#bar". You do in sh. You don't in rc: > Byron thinks # should introduce a comment even if it is in the middle > of a word. I think this is plainly wrong. Opinions? Why should it be special? What's wrong with echo foo'#'bar ? It's not as if octothorpe is exactly the most common character, and I think it's actually harder for people to parse by your rules, as they have to consider the context of whether it is preceeded by whitespace. As for a=( 1 \ # 2\ 3) Either: a=( 1 3) or: a=( 1 #2 ---- error Seem reasonable (in the second one you'd actually get a second error from the ``3)''). I can see the former as being handy, and the latter as being consistent and simple. I vote for consistent and simple. I can see no justification for the interpretation: a=( 1 # 2 3) ---- error ../Dave From rc-owner Sat Mar 14 13:45:18 1992 Received: from Princeton.EDU ([128.112.128.1]) by archone.tamu.edu with SMTP id <45332>; Sat, 14 Mar 1992 13:39:47 -0600 Received: from phoenix.Princeton.EDU by Princeton.EDU (5.65b/2.86/princeton) id AA04541; Sat, 14 Mar 92 14:39:29 -0500 Received: from burn.Princeton.EDU by phoenix (5.65b/1.111) id AA13698; Sat, 14 Mar 92 14:39:22 -0500 From: "Emin G. Sirer" Received: by burn.Princeton.EDU (4.1/CS_002_Cluster_Client) id AA22325; Sat, 14 Mar 92 14:39:18 EST Date: Sat, 14 Mar 1992 13:39:18 -0600 Message-Id: <9203141939.AA22325@burn.Princeton.EDU> To: rc@archone.tamu.edu Subject: Re: comments, newlines >From: Dave Mason >Subject: RE: comments, newlines >Date: Fri, 13 Mar 1992 16:44:35 -0600 > >> From: John (I've got some bad news for you, sunshine) Mackin >> Date: Fri, 13 Mar 1992 05:14:22 -0500 > >> I claim that # should only be seen as a comment introducer if it is >> preceded by whitespace or at the start of the line. So if you do >> echo foo#bar >> you should, in my view, get "foo#bar". You do in sh. You don't in rc: >> Byron thinks # should introduce a comment even if it is in the middle >> of a word. I think this is plainly wrong. Opinions? > >Why should it be special? Because almost all the other metacharacters are 'special' in some way or another. For example, echo f* (or f[a-c]*) will either expand (if there are matching files in .) or stay as it is. I think that that behaviour is very strange, and even unjustifiable. No part of shell behaviour should depend on the environment (i.e. current working directory). I think csh's the only one that's got it right (gasp). Talking about strangeness, how do you explain to someone the bizarre parenthesis behaviour ? They seem to introduce lists one-minute (a=(a b c)) and seem to mark the clauses to the while and if statements the next. 'Special' is not the right word. All these characters are already special anyway (look in lexer.c; they are called special characters). The key thing is whether the rules governing their use make sense. I, for one, find the parenthesis usage very natural. The rule is that they delimit lists unless they follow while or if, when they delimit clauses (thus we don't see code like 'while true echo foo;' I think it is much more desirable that we use 'while(true) echo foo'). The rule for '#' should be that it introduces comments iff it is preceded by whitespace, else it's a regular character. And the kind of change we're talking about here only involves a trivial change in the lexer. > What's wrong with > echo foo'#'bar What's wrong with lpr -Gr2 -#3 foo.ps ? Why doesn't it print anything ? Do you really prefer lpr -Gr2 -'#'3 foo.ps ? Is that better syntax ? Is it more readable ? >It's not as if octothorpe is exactly the most common character, and I >think it's actually harder for people to parse by your rules, as they have >to consider the context of whether it is preceeded by whitespace. A lot of the lexical analysis (not parsing) is done in a context sensitive manner; what's the big deal ? I think sh behaviour is more desirable given that the rule is very simple (both to remember and to implement); so much so that remembering to escape the number sign is much harder than keeping the rule in mind (in fact, you don't even have to). Simplicity does not mean cumbersome notation. Gun. From rc-owner Sun Mar 15 02:41:24 1992 Received: from joyce.cs.su.oz.au ([129.78.8.208]) by archone.tamu.edu with SMTP id <45332>; Sun, 15 Mar 1992 02:36:16 -0600 To: rc@archone.tamu.edu Message-ID: <19920315183107.28843.frobozz@karl.cs.su.OZ.AU> In-Reply-To: <9203141939.AA22325@burn.Princeton.EDU> From: James Matthew Farrow Date: Sun, 15 Mar 1992 17:31:07 -0600 Organisation: Basser Dept of Computer Science, Sydney University, Australia X-Name: Boggo the Wonder Cat X-Face: (U?GH?osc&;NtYo%_FS>9<5bs*|E$grN|sun}Rqt'daJ6(yXXs4dr}`_@gc:q1Y_ xA%VF^,4h=}},mu?*~pcrAk2,{4D")109dr=+JCp&BDS(*]5RnZQ+Fehl;hI!t-( z{JHWYQ6CzsEBllWb,(ojs'2X!Iw?R22RtA|6Qc.gIie=,=NCp`?0^F^tF=>HWTv!h#WCDgGp.WVc& X-Mailer: Frobozz Magic Mailer [1.5] Subject: Re: comments, newlines I am in favour of John's view. I always getting caught by special characters ([=~#]) always being special and having to quote them which makes commands look really ugly and less readable sometimes. For example, the What's wrong with lpr -Gr2 -#3 foo.ps ? Why doesn't it print anything ? Do you really prefer lpr -Gr2 -'#'3 foo.ps ? Is that better syntax ? Is it more readable ? that Emin mentioned. Matty. From rc-owner Sun Mar 15 12:00:02 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45336>; Sun, 15 Mar 1992 11:55:43 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2539>; Sun, 15 Mar 1992 12:55:05 -0500 To: rc@archone.tamu.edu Subject: Re: comments, newlines In-reply-to: Your message of "Sun, 15 Mar 92 18:31:07 EST." <19920315183107.28843.frobozz@karl.cs.su.OZ.AU> Date: Sun, 15 Mar 1992 11:54:49 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Mar15.125505est.2539@groucho.cs.psu.edu> | I am in favour of John's view. I always getting caught by special | characters ([=~#]) always being special and having to quote them which | makes commands look really ugly and less readable sometimes. The only such character I've had problems with is '='. Rc and make are like csh and uucp. :-) But back to lists... Wouldn't it be nice if this were legal? x=(1 2 3) (no backslashes) Then you could easily comment out parts. From rc-owner Sun Mar 15 19:18:28 1992 Received: from andrew.cmu.edu ([128.2.11.131]) by archone.tamu.edu with SMTP id <45334>; Sun, 15 Mar 1992 19:15:52 -0600 Received: by andrew.cmu.edu (5.54/3.15) id for rc@archone.tamu.edu; Sun, 15 Mar 92 20:15:33 EST Received: via switchmail; Sun, 15 Mar 1992 20:15:25 -0500 (EST) Received: from hartsfield.res.andrew.cmu.edu via qmail ID ; Sun, 15 Mar 1992 20:14:54 -0500 (EST) Received: from hartsfield.res.andrew.cmu.edu via qmail ID ; Sun, 15 Mar 1992 20:14:50 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hartsfield.res.andrew.cmu.edu.pmax.ul4 via MS.5.6.hartsfield.res.andrew.cmu.edu.pmax_ul4; Sun, 15 Mar 1992 20:14:50 -0500 (EST) Message-Id: Date: Sun, 15 Mar 1992 19:14:50 -0600 From: "Josh N. Pritikin" To: rc@archone.tamu.edu Subject: Reactive Keyboard Beak: Is not. I'm new to this mailing list but I'm going to take a risk and post this anyway. I recently found a program called Reactive Keyboard. Here's a description taken from the man page: The Reactive Keyboard is a general-purpose command-line editor with the addition of predictive text generation. It interfaces with a standard shell and allows simple editing of input lines. It will also predict new input lines based on previous input. If you want to get a copy, I believe its on export.lcs.mit.edu. My thought is that rk could replace readline and history as an interactive interface to rc... ( Josh Pritikin jpab+@andrew.cmu.edu ( It might be hot in Pittsburgh, but at least it's humid. From rc-owner Sun Mar 15 23:03:39 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45340>; Sun, 15 Mar 1992 23:00:32 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2541>; Sun, 15 Mar 1992 23:59:56 -0500 To: "Josh N. Pritikin" cc: rc@archone.tamu.edu Subject: Re: Reactive Keyboard In-reply-to: Your message of "Sun, 15 Mar 92 20:14:50 EST." Date: Sun, 15 Mar 1992 22:59:46 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Mar15.235956est.2541@groucho.cs.psu.edu> | If you want to get a copy, I believe its on export.lcs.mit.edu. My | thought is that rk could replace readline and history as an interactive | interface to rc... Rk is a lot of fun. If your terminal can do underlining, be sure to turn that on in the rksetup; it looks much better. (If you aren't using a VAX, you'll need to fix a bug in rksetup where it assumes that NULL == "" for some of the termcap strings.) One problem, however, with rk and related tools (atty, fep, etc) is that they do completion incorrectly. They can (and do) try and track the current directory, but even in principle that is wrong, since the shell might be executing on a different machine than the input editor. I've been thinking about clean ways to allow the shell to do completion and communicate with the editor; it seems like that would be the best overall scheme. One other problem with these and other pty related items is that they all do pty handling in idiosyncratic ways. Even worse, unless they can run as root, they cannot change pty modes and ownership nor make entries in e.g. /etc/utmp. (Rk suffers that flaw.) The best fix for that stuff is to rip out all the custom pty code, and drop in a nice modular replacement, like Dan Bernstein's pty program. It isn't perfect, but its a good start. | ( It might be hot in Pittsburgh, but at least it's humid. Almost as nice as Philly, hey? :-) From rc-owner Mon Mar 16 13:26:16 1992 Received: from po5.andrew.cmu.edu ([128.2.10.105]) by archone.tamu.edu with SMTP id <45332>; Mon, 16 Mar 1992 13:21:15 -0600 Received: by po5.andrew.cmu.edu (5.54/3.15) id for rc@archone.tamu.edu; Mon, 16 Mar 92 14:21:07 EST Received: via switchmail; Mon, 16 Mar 1992 14:21:06 -0500 (EST) Received: from niobe.weh.andrew.cmu.edu via qmail ID ; Mon, 16 Mar 1992 14:19:49 -0500 (EST) Received: from niobe.weh.andrew.cmu.edu via qmail ID ; Mon, 16 Mar 1992 14:19:39 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.niobe.weh.andrew.cmu.edu.pmax.ul4 via MS.5.6.niobe.weh.andrew.cmu.edu.pmax_ul4; Mon, 16 Mar 1992 14:19:38 -0500 (EST) Message-Id: Date: Mon, 16 Mar 1992 13:19:38 -0600 From: "Josh N. Pritikin" To: rc@archone.tamu.edu Subject: Re: Reactive Keyboard In-Reply-To: <9203161203.AA04226@piggy.ucsb.edu> References: <9203161203.AA04226@piggy.ucsb.edu> Beak: Is not. > perhaps fd passing? fd#10 (<--some well-known number) would be a pipe > to/from the editor where you could write() changes in cwd? (fd 3 is > used by Dan Bernstein's pty package, for /dev/tty, btw.) Yah. I was going to suggest a similar mechanism. > we're sort of going off the subject of rc here, but hopefully, enough > of us are concerned about making *modular* (not in the shell) line > editing interfaces that we can have some talk about it. besides, rc > is perfect, already, right?? :-) That's why I brought it up. rc is pretty much exacly what I want in a shell (except for its lack of job control :-) but I would never consider using it without emacs like editing functions. I feel that something like rk provides this without bloating rc with unnecessary features. From this point of view, rk and similar hacks seems quite relivent to this list. Currently, I don't know enough about the tty to try hacking rc-rk communication in but it sounds like an interesting project if I have time. ( Josh Pritikin jpab+@andrew.cmu.edu ( It might be hot in Pittsburgh, but at least it's humid. From rc-owner Mon Mar 16 14:07:16 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45334>; Mon, 16 Mar 1992 14:03:27 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2541>; Mon, 16 Mar 1992 15:02:46 -0500 To: rc@archone.tamu.edu Subject: Re: Reactive Keyboard In-reply-to: Your message of "Mon, 16 Mar 92 07:03:43 EST." <9203161203.AA04226@piggy.ucsb.edu> Date: Mon, 16 Mar 1992 14:02:36 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Mar16.150246est.2541@groucho.cs.psu.edu> | ... i fixed by hacking the completion code to get pwd every time. :( | | the only drawbacks here are, if you are working in another command | processor (ftp, a line editor, ???) ... Exactly. A solution that isn't robust isn't very statisfying to me. (Fep "front end processor" is an ile like thing that was posted to the net long ago.) | perhaps fd passing? ... Yes, fd passing might be useful. | ... except on suns that have a world-writable utmp... Not on _my_ Sun! :-) This is an exercise in tidying things up, after all. | (then we | still have problems with pty ownership etc.). i can't conceive of a | flexible editor that *could* run as root. perhaps one that setuid()s | away from it right after making pty/utmp changes; but how to change | the pty back when the process dies? Yes, some tools, like screen, do that. You just have to make sure they don't die unexpectedly. Dan's pty does that job in addition to making sure all the system files are maintained, and taking care to run the shell with the right uid. From rc-owner Thu Mar 19 07:02:57 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.1.2]) by archone.tamu.edu with SMTP id <45329>; Thu, 19 Mar 1992 06:56:54 -0600 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA11100; Thu, 19 Mar 92 13:54:57 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA02417; Thu, 19 Mar 92 13:54:55 +0100 Date: Thu, 19 Mar 1992 06:54:55 -0600 From: malte@techfak.uni-bielefeld.de Message-Id: <9203191254.AA02417@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: an improvement(?) suggestion and a question Hello *, in rc's man page it says that $0 is set to name of the function during its execution, so a naive thought came to my mind: fn sighup sigint { echo $progname was killed by $0 | mail somebody exit 2 } But this does not work since $0 when catching a signal is the name of of the function rc was currently working on. To change this, I have two suggestions: 1) Change the signal handler to place the signals name in $0 and allow $* to be referenced with negative indices, with $*(-1) evaluating to the name of the function the present function was called from, $*(-2) ... This is a more general solution, or 2) Introduce a new special variable $signal which evaluates to the name of the most current signal, so that the above example will read ... echo $progname was killed by $signal | mail somebody ... How about that? Now the question: Does anybody know of a more elegant way to temporarily disable the '-e' feature (exit on failure)? The only way I can think of is command || true Malte. From rc-owner Thu Mar 19 07:43:31 1992 Received: from eros.uknet.ac.uk ([192.91.199.2]) by archone.tamu.edu with SMTP id <45331>; Thu, 19 Mar 1992 07:40:39 -0600 Received: from ibmpcug.co.uk by eros.uknet.ac.uk with UUCP id <14622-0@eros.uknet.ac.uk>; Thu, 19 Mar 1992 13:40:17 +0000 Received: by ibmpcug.co.uk (smail2.5) id AA02384; 19 Mar 92 13:25:10 GMT (Thu) X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. In-Reply-To: <9203191254.AA02417@dahlie.techfak.uni-bielefeld.de> Organization: The IBM PC User Group, UK. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: rc@archone.tamu.edu Subject: Re: an improvement(?) suggestion and a question Message-Id: <9203191325.AA02380@ibmpcug.co.uk> Date: Thu, 19 Mar 1992 07:25:09 -0600 From: Matthew Farwell In article <9203191254.AA02417@dahlie.techfak.uni-bielefeld.de> malte@techfak.uni-bielefeld.de writes: >in rc's man page it says that $0 is set to name of the function during its >execution, so a naive thought came to my mind: > > fn sighup sigint { > echo $progname was killed by $0 | mail somebody > exit 2 > } > >But this does not work since $0 when catching a signal is the name of >of the function rc was currently working on. > >To change this, I have two suggestions: > 1) Change the signal handler to place the signals name in $0 > and allow $* to be referenced with negative indices, with > $*(-1) evaluating to the name of the function the present > function was called from, $*(-2) ... > >This is a more general solution, or > > 2) Introduce a new special variable $signal which evaluates to > the name of the most current signal, so that the above example > will read > ... > echo $progname was killed by $signal | mail somebody > ... Or set $1 inside a signal handler to the name of the signal sent to the function, ie fn sigint sighup { echo $0 killed by signal $1 } Dylan. -- re-invented wheels are often square -- Henry Spencer From rc-owner Fri Mar 20 12:06:49 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45330>; Fri, 20 Mar 1992 11:59:07 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2603>; Fri, 20 Mar 1992 12:58:01 -0500 To: rc@archone.tamu.edu Subject: redirection bug Date: Fri, 20 Mar 1992 11:57:46 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Mar20.125801est.2603@groucho.cs.psu.edu> rsh roke exec /bin/rc >[0=] >[1=] >[2=] >[3=] >[4=] >[5=] >[6=] /import/X11R5/bin/xterm -display roke:0 & panic: unexpected node in doredirs! From rc-owner Fri Mar 20 13:25:37 1992 Received: from lisa.cs.widener.edu ([147.31.254.23]) by archone.tamu.edu with SMTP id <45332>; Fri, 20 Mar 1992 13:18:12 -0600 Received: by lisa.cs.widener.edu id AA28449 (5.65c/Widener-4.1 for rc@archone.tamu.edu); Fri, 20 Mar 1992 14:17:57 -0500 Date: Fri, 20 Mar 1992 13:17:57 -0600 From: Brendan Kehoe Message-Id: <199203201917.AA28449@lisa.cs.widener.edu> To: rc@archone.tamu.edu In-Reply-To: schwartz@groucho.cs.psu.edu's message of Fri, 20 Mar 1992 11:57:46 -0600 <92Mar20.125801est.2603@groucho.cs.psu.edu> Subject: redirection bug Reply-To: brendan@cs.widener.edu Date: Fri, 20 Mar 1992 11:57:46 -0600 From: schwartz@groucho.cs.psu.edu rsh roke exec /bin/rc >[0=] >[1=] >[2=] >[3=] >[4=] >[5=] >[6=] /import/X11R5/bin/xterm -display roke:0 & panic: unexpected node in doredirs! It may be a little late, but could I persuade you to change name of panic()? :) Even though it doesn't have any side effects, I always wake up whenever I see it make a message like that. I like my sleep. :) From rc-owner Fri Mar 20 13:31:31 1992 Received: by archone.tamu.edu id <45334>; Fri, 20 Mar 1992 13:27:30 -0600 From: Byron Rakitzis To: rc Subject: Re: redirection bug Message-Id: <92Mar20.132730cst.45334@archone.tamu.edu> Date: Fri, 20 Mar 1992 13:27:29 -0600 Yes, Brendan, I've already changed the name to "rc panic". I realized the inappropriateness of the name some while ago! :-) From rc-owner Tue Mar 24 19:19:56 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45330>; Tue, 24 Mar 1992 19:13:39 -0600 Received: by groucho.cs.psu.edu id <2538>; Tue, 24 Mar 1992 20:12:19 -0500 From: Scott Schwartz To: rc@archone.tamu.edu Subject: more lists Message-Id: <92Mar24.201219est.2538@groucho.cs.psu.edu> Date: Tue, 24 Mar 1992 19:12:06 -0600 Given that while (this # that other) { } is legal, doesn't it seem strange to anyone besides me that w = (this # that other) isn't? From rc-owner Wed Mar 25 14:18:06 1992 Received: by archone.tamu.edu id <45331>; Wed, 25 Mar 1992 14:11:39 -0600 From: Byron Rakitzis To: rc Subject: Re: more lists Message-Id: <92Mar25.141139cst.45331@archone.tamu.edu> Date: Wed, 25 Mar 1992 14:11:35 -0600 Hm. Well, td's grammar doesn't allow it. It takes some fiddling around because '\n' is a token in rc, not just whitespace, but I don't see why it shouldn't be doable. From rc-owner Wed Mar 25 15:51:01 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45332>; Wed, 25 Mar 1992 15:44:38 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Wed, 25 Mar 1992 16:43:40 -0500 To: Byron Rakitzis cc: rc@archone.tamu.edu Subject: Re: more lists In-reply-to: Your message of "Wed, 25 Mar 92 15:11:35 EST." <92Mar25.141139cst.45331@archone.tamu.edu> Date: Wed, 25 Mar 1992 15:43:22 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Mar25.164340est.2538@groucho.cs.psu.edu> | Hm. Well, td's grammar doesn't allow it. It takes some fiddling around | because '\n' is a token in rc, not just whitespace, but I don't see | why it shouldn't be doable. The question was more philosophical than practical. I just wonder what posessed him to do it that way, when the alternative seems clearer and more useful, at least in scripts. From rc-owner Sat Mar 28 02:45:06 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45331>; Sat, 28 Mar 1992 02:22:21 -0600 Received: by groucho.cs.psu.edu id <2613>; Sat, 28 Mar 1992 03:21:45 -0500 From: Scott Schwartz To: rc@archone.tamu.edu Subject: double quotes Message-Id: <92Mar28.032145est.2613@groucho.cs.psu.edu> Date: Sat, 28 Mar 1992 02:21:36 -0600 I think rc is identifying double quotes incorrectly. To test this, type ; ''xx' or ; ''xx'' ' That sort of thing. What do you all think? From rc-owner Sat Mar 28 03:06:53 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45334>; Sat, 28 Mar 1992 02:51:37 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2756>; Sat, 28 Mar 1992 03:51:10 -0500 To: rc@archone.tamu.edu Subject: Re: double quotes In-reply-to: schwartz's message of Sat, 28 Mar 92 03:21:36 -0500. <92Mar28.032145est.2613@groucho.cs.psu.edu> Date: Sat, 28 Mar 1992 02:50:57 -0600 From: Chris Siebenmann Message-Id: <92Mar28.035110est.2756@hawkwind.utcs.toronto.edu> I don't see anything wrong with either example you gave; rc behaves just as it's documented to in both cases (the manual page is somewhat unclear on this, but not the bit about the minimal sequence to get a single quote and how to represent the empty string). - cks From rc-owner Sat Mar 28 13:02:22 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45331>; Sat, 28 Mar 1992 13:00:07 -0600 Received: by groucho.cs.psu.edu id <2583>; Sat, 28 Mar 1992 13:59:34 -0500 To: rc@archone.tamu.edu Subject: Re: double quotes In-reply-to: Your message of "Sat, 28 Mar 92 03:46:32 EST." <92Mar28.024641cst.45334@archone.tamu.edu> Date: Sat, 28 Mar 1992 12:59:17 -0600 From: Scott Schwartz Message-Id: <92Mar28.135934est.2583@groucho.cs.psu.edu> You won't believe this, but it works now. :-) Last night (I have witnesses!) the first case somehow came out wrong---it must have been a multiline typo. Sorry for the false alarm. From rc-owner Mon Mar 30 12:22:15 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45331>; Mon, 30 Mar 1992 12:16:33 -0600 Received: by groucho.cs.psu.edu id <2538>; Mon, 30 Mar 1992 13:15:41 -0500 From: Scott Schwartz To: rc@archone.tamu.edu Subject: more ile Message-Id: <92Mar30.131541est.2538@groucho.cs.psu.edu> Date: Mon, 30 Mar 1992 12:15:40 -0600 Here are some hacks on ile to make it use Dan Bernstein's pty program, rather than doing pty munging for itself. After a whole hour of use, it seems to mostly work. :-) Some previous features got left out for no reason (like lflag). New features are that utmp and pty mode/ownership are now correctly maintained (although you'll need a patch for pty to make the latter work straight: comment out line 234 of ptymisc.c) (context diff from roughly the version that Rich posted most recently.) *** 1.3 1992/02/09 07:16:44 --- ile.c 1992/03/30 18:12:47 *************** *** 34,39 **** --- 34,42 ---- ** ** Uses the termcap library. */ + /* + ** Hacked on by Rich Salz and Scott Schwartz. + */ #include #include #include *************** *** 46,51 **** --- 49,55 ---- #include #include #include + #include #include #include *************** *** 157,164 **** int TTYmode; int TTYmaster; int TTYslave; - char ttydev[] = "/dev/ttyxx"; - char ptydev[] = "/dev/ptyxx"; /* Definitions of system stuff. */ extern int optind; --- 161,166 ---- *************** *** 177,216 **** extern void exit(); extern void _exit(); - - /* - ** Open a pty. Try pairs in order until we find a free one. - */ - void - getpty() - { - char *letter; - char *devindex; - int i; - int j; - - i = strlen(ttydev); - j = strlen(ptydev); - for (letter = "pqrstuvwxyz"; *letter; letter++) { - ttydev[i - 2] = *letter; - ptydev[j - 2] = *letter; - for (devindex = "0123456789abcdef"; *devindex; devindex++) { - ttydev[i - 1] = *devindex; - ptydev[j - 1] = *devindex; - if ((TTYmaster = open(ptydev, O_RDWR)) >= 0) { - if ((TTYslave = open(ttydev, O_RDWR)) >= 0) - return; - (void)close(TTYmaster); - } - } - } - - perror("ile (can't get pty)"); - exit(1); - /* NOTREACHED */ - } - - /* ** Move past the digits and * in front of an termcap entry. */ --- 179,184 ---- *************** *** 287,365 **** TTYnewsize = TRUE; } - - /* - ** set/clear the utmp slot for the pty - */ - void - setutmp(set) - BOOL set; - { - int f; - int old0; - int old1; - int old2; - int slot; - struct utmp ut; - struct passwd *pw; - char *p; - - /* Must make fd's 0,1,2 correspond to TTYslave for ttyslot() to - * function. Ugh! Why doesn't ttyslot() accept a fd argument? */ - old0 = dup(0); - old1 = dup(1); - old2 = dup(2); - if (old0 < 0 || old1 < 0 || old2 < 0) { - perror("ile: dup"); - return; - } - - (void)dup2(TTYslave, 0); - (void)dup2(TTYslave, 1); - (void)dup2(TTYslave, 2); - slot = ttyslot(); - - /* put the fd's back */ - (void)dup2(old0, 0); - (void)dup2(old1, 1); - (void)dup2(old2, 2); - (void)close(old0); - (void)close(old1); - (void)close(old2); - - if (slot < 0) { - perror("ile (who are you?)"); - return; - } - - if ((f = open("/etc/utmp", O_WRONLY)) < 0) - return; - - bzero((char *)&ut, sizeof ut); - - if (set) { - if ((pw = getpwuid(getuid())) == NULL) { - perror("ile (getpwuid failed)"); - (void)close(f); - return; - } - - /* skip "/dev/" */ - if ((p = rindex(ttydev, '/')) == NULL) - p = ttydev; - else - p++; - - (void)strncpy(ut.ut_line, p, sizeof ut.ut_line); - (void)strncpy(ut.ut_name, pw->pw_name, sizeof ut.ut_name); - (void)time(&ut.ut_time); - } - (void)lseek(f, (long)(slot * sizeof ut), L_SET); - (void)write(f, (char *)&ut, sizeof ut); - (void)close(f); - } - - /* ** Clean up and leave. This function is bound to the SIGCHLD signal so ** that when the child process exits, so does ile. It is also called when --- 255,260 ---- *************** *** 372,390 **** /* kill off the child process */ (void)ioctl(TTYslave, TIOCGPGRP, (char *)&pgrp); ! (void)killpg(pgrp, SIGTERM); ! ! /* "logout" the user */ ! setutmp(FALSE); ! ! /* restore TTY, close PTY */ ! (void)ioctl(STDIN, TIOCSETP, &TTYsgttyb); ! (void)ioctl(STDIN, TIOCSETC, &TTYtchars); ! (void)ioctl(STDIN, TIOCSLTC, &TTYltchars); ! (void)ioctl(STDIN, TIOCLSET, &TTYmode); (void)close(TTYmaster); (void)close(TTYslave); - /* make things look nice */ PUT(cnl); exit(0); --- 267,276 ---- /* kill off the child process */ (void)ioctl(TTYslave, TIOCGPGRP, (char *)&pgrp); ! (void)killpg(pgrp, SIGHUP); ! /*(void)killpg(pgrp, SIGTERM);*/ (void)close(TTYmaster); (void)close(TTYslave); /* make things look nice */ PUT(cnl); exit(0); *************** *** 1619,1666 **** (void)signal(SIGINT, clean_up); (void)signal(SIGWINCH, change_window); - /* Get the current ttys state and copy it to the TTYslave. */ - (void)ioctl(STDIN, TIOCGETP, &TTYsgttyb); - (void)ioctl(TTYslave, TIOCSETP, &TTYsgttyb); - (void)ioctl(STDIN, TIOCGETD, &i); - (void)ioctl(TTYslave, TIOCSETD, &i); - (void)ioctl(STDIN, TIOCGETC, &TTYtchars); - (void)ioctl(TTYslave, TIOCSETC, &TTYtchars); - (void)ioctl(STDIN, TIOCLGET, &TTYmode); - (void)ioctl(TTYslave, TIOCLSET, &TTYmode); - (void)ioctl(STDIN, TIOCGLTC, &TTYltchars); - (void)ioctl(TTYslave, TIOCSLTC, &TTYltchars); - (void)ioctl(STDIN, TIOCGWINSZ, &TTYwinsize); - (void)ioctl(TTYslave, TIOCSWINSZ, &TTYwinsize); TTYnewsize = FALSE; - /* "login" the user */ - setutmp(TRUE); - - /* Simulate RAW but allow original parity to work. Thus we use - * CBREAK with all the options turned off. */ - params = TTYsgttyb; - params.sg_flags = CBREAK; - (void)ioctl(STDIN, TIOCSETP, ¶ms); - tchars = TTYtchars; - tchars.t_intrc = -1; - tchars.t_quitc = -1; - tchars.t_startc = -1; - tchars.t_stopc = -1; - tchars.t_eofc = -1; - tchars.t_brkc = -1; - (void)ioctl(STDIN, TIOCSETC, &tchars); - ltchars = TTYltchars; - ltchars.t_suspc = -1; - ltchars.t_dsuspc = -1; - ltchars.t_rprntc = -1; - ltchars.t_flushc = -1; - ltchars.t_lnextc = -1; - (void)ioctl(STDIN, TIOCSLTC, <chars); - - i = LNOFLSH | LDECCTQ | LLITOUT; - (void)ioctl(STDIN, TIOCLSET, &i); - /* Set up the editor. */ edit = edit_0; point = 0; --- 1505,1512 ---- *************** *** 1721,1772 **** ** The child process. Make the pty the controlling terminal and bind it ** to stdin, stdout, and stderr. Then exec the users program. */ - void - child(lflag, av) - BOOL lflag; - char *av[]; - { - char *new; - char *path; - int tty; - - /* close all file descriptors */ - (void)close(STDIN); - (void)close(STDOUT); - (void)close(STDERR); - (void)close(TTYslave); - (void)close(TTYmaster); ! /* get the pty as the controlling terminal */ ! if ((tty = open("/dev/tty", O_RDWR) < 0) ! || ioctl(tty, TIOCNOTTY, 0) < 0 ! || close(tty) < 0) ! perror("ile"); ! if ((TTYslave = open(ttydev, O_RDWR)) < 0) ! perror("ile"); ! else { ! (void)dup2(TTYslave, STDOUT); ! (void)dup2(TTYslave, STDERR); } - - /* Get pathname. */ - path = av[0]; - if ((av[0] = strrchr(path, '/')) != NULL) - av[0]++; - else - av[0] = path; - if (lflag) { - new = malloc((unsigned int)(1 + strlen(av[0]) + 1)); - new[0] = '-'; - (void)strcpy(&new[1], av[0]); - av[0] = new; - } - (void)execvp(path, av); - perror(path); - _exit(1); - /* NOTREACHED */ } /* ** Set up default key bindings and delimeters. --- 1567,1623 ---- ** The child process. Make the pty the controlling terminal and bind it ** to stdin, stdout, and stderr. Then exec the users program. */ ! void fork_pty (mp, sp, lflag, args) ! int *mp, *sp; ! int lflag; ! char *args; ! { ! int sv[2]; ! char buf[1024]; ! ! if (socketpair(AF_UNIX, SOCK_STREAM, PF_UNSPEC, sv) < 0) ! perror("socketpair"), exit(1); ! ! switch (fork()) { ! case -1: ! perror("fork"); ! exit(1); ! case 0: ! {int i; for (i = 0; i < FD_SETSIZE; ++i) if (i != sv[1]) close(i); } ! dup(sv[1], 0); dup(sv[1], 1); dup(sv[1], 2); ! strcpy(buf, "/bin/tty;exec "); ! strcat(buf, args); ! execlp("pty", "pty", "-D", "-xuc", "/bin/sh", "-c", buf, 0); ! perror("execlp"); ! _exit(1); ! /*NOTREACHED*/ ! } ! close(sv[1]); ! *mp = sv[0]; ! read_line(*mp, buf, sizeof(buf)); ! if ((*sp = open(buf, 2)) < 0) { ! write(2, "ile/slave: `", 12); ! write(2, buf, strlen(buf)); ! write(2, "': ", 3); ! perror("open"); ! exit(1); } } + int read_line(fd, buf, n) + int fd; char* buf; int n; + { + int r; + while (--n > 0) { + r = read(fd, buf, 1); + if (r <= 0) break; + if (*buf == '\r') continue; + if (*buf == '\n') break; + ++buf; + } + *buf = 0; + } /* ** Set up default key bindings and delimeters. *************** *** 2069,2076 **** } /* Configure ourserlves. */ ! PUT("ile Rev. 2($Revision: 1.3 $)\n"); ! getpty(); get_termcap(); if ((homedir = getenv("HOME")) == NULL) homedir = "/"; --- 1920,1926 ---- } /* Configure ourserlves. */ ! PUT("ile Rev. 2 ($Author: schwartz $ $Revision: 1.9 $)\n"); get_termcap(); if ((homedir = getenv("HOME")) == NULL) homedir = "/"; *************** *** 2078,2097 **** user_bindings(initfile); if (getwd(currentdir) == NULL) (void)strcpy(currentdir, homedir); ! ! i = fork(); ! switch (i) { ! default: /* parent process */ ! ile(); ! break; ! case 0: /* child process */ ! child(lflag, av); ! /* NOTREACHED */ ! case -1: /* fork failed */ ! perror("ile"); ! exit(1); ! /* NOTREACHED */ ! } exit(0); return 0; } --- 1928,1935 ---- user_bindings(initfile); if (getwd(currentdir) == NULL) (void)strcpy(currentdir, homedir); ! fork_pty (&TTYmaster, &TTYslave, lflag, av[0]); ! ile(); exit(0); return 0; } From rc-owner Wed Apr 1 19:37:08 1992 Received: by archone.tamu.edu id <45337>; Wed, 1 Apr 1992 19:31:24 -0600 From: Byron Rakitzis To: rc Subject: rc-1.4beta Message-Id: <92Apr1.193124cst.45337@archone.tamu.edu> Date: Wed, 1 Apr 1992 19:31:16 -0600 Work on rc has been proceeding at a steady, but far reduced pace ever since the last major release (1.2, Sept. 1991). I think it's about time to put out another version into the various archives, but quite a lot has happened since February (when 1.3beta was announced to this list) so I would like to try your patience and ask you to review what I am now calling "1.4beta". rc unfortunately still needs some work before I can put my conscience to rest and say that I've done everything that needs doing for now, e.g., fixed every bug I knew about. In particular, there are these issues in my mind: 1) editline. Last time I checked it, it was a little flaky, and if it's going to be distributed with rc I want to make sure it's solid. If you'll allow a little immodesty, having put hundreds of hours of my own time into rc (not to speak of the generous help I have received from many of you), if I am going to pair something else with rc in an archive, I would like to make sure it is at least as stable. This is something I just haven't gotten around to personally overseeing yet. Maybe I shouldn't be so paranoid, but... 2) trip.rc. It needs to be improved, and work on trip.rc is just tedious, boring and time-consuming. Here's a current list of basic-block coverage I've got with a ~500 line rc script now: main.tcov: 100.00 Percent of the file executed list.tcov: 100.00 Percent of the file executed getopt.tcov: 100.00 Percent of the file executed glob.tcov: 98.91 Percent of the file executed hash.tcov: 96.52 Percent of the file executed match.tcov: 95.56 Percent of the file executed heredoc.tcov: 95.56 Percent of the file executed lex.tcov: 94.77 Percent of the file executed var.tcov: 94.67 Percent of the file executed fn.tcov: 94.44 Percent of the file executed which.tcov: 92.31 Percent of the file executed wait.tcov: 92.11 Percent of the file executed tree.tcov: 91.89 Percent of the file executed except.tcov: 90.32 Percent of the file executed builtins.tcov: 89.82 Percent of the file executed nalloc.tcov: 88.24 Percent of the file executed status.tcov: 87.50 Percent of the file executed exec.tcov: 87.50 Percent of the file executed input.tcov: 87.10 Percent of the file executed footobar.tcov: 83.21 Percent of the file executed walk.tcov: 82.64 Percent of the file executed glom.tcov: 80.77 Percent of the file executed utils.tcov: 77.78 Percent of the file executed signal.tcov: 76.00 Percent of the file executed redir.tcov: 71.88 Percent of the file executed print.tcov: 66.67 Percent of the file executed open.tcov: 66.67 Percent of the file executed Some of these percentages will never reach 100, unless I simulate failures to fork(), malloc(), pipe(), etc. Some of the code coverage in trip.rc is completely superficial, and real tests need to be devised. Other parts of the code are just completely untested (by trip.rc). Of course, in principle such a test suite is useless because it will never uncover all the bugs. If anyone has any suggestions about how to make a test suite like this more useful, I'm listening. You could help out the trip.rc effort by running it on your Unix and letting me know if 1) there are any bugs in the script, or 2) if there are any bugs in rc. Of course, if you're foolhardy enough to want to extend trip.rc yourself, you are more than welcome! 3) race condition. There is a race condition in the fork-exec sequence that rc uses to start a process and wait for it to finish. Essentially, it is possible to send a SIGINT to rc and to have it get lost. This is because rc uses the following paradigm for spawning a process: fork/exec ignore SIGINT wait() restore SIGINT If a SIGINT arrives after the wait() but before SIGINT's handler is restored, the signal gets lost. The solution that /bin/sh uses is to simply collect SIGINTs that arrive during a wait(). However, I find this unacceptable for the following reason: a signal destined for a child is usually not destined for the shell as well. For example, in sh: if true; then ed bar fi If I type "^C" inside ed to abort some ed operation, let ed catch the SIGINT, continue to edit and then exit ed normally, the command "bar" will never get executed. Whereas, if (true) { ed bar } does try to find bar. So it's a dilemma: adopt poor semantics for SIGINT, or allow a race condition into the code. I really don't know which one is worse right now, so I'm leaving things as they are (though I must note that 1.4beta signals are more reliable than in previous versions---there were other problems with signals that have been fixed in the current release). 4) FIFO's. As long as I'm picking nits, I should mention that this (mis)feature of rc seems to cause more trouble than it's worth. I've mostly ignored it up to now, and it's easily the flakiest part of the shell. Part of the problem is that FIFO's themselves are so flaky. e.g., on a Sun if you put one on a tmpfs filesystem, the machine can crash(!). I want to do something to clean up this mess, if possible. Anyway, here's a list of changes since 1.3beta, and of course rc is available in the usual way. I'm using a tar file format because of the non-printable characters in trip.rc. Changes since 1.3beta: New Makefile/config.h setup. builtin echo may now be conditionally included out, to use a Goldwynism. builtin exit takes any legal exit status. If the status is not a single digit, (e.g., (0 1 2), sigint, (sigiot+core 0), etc.) rc exits with 1. rc's exit status is zero if and only if the status given to exit is all zeros. (or $status is all zeros, of course) (BTW, having "exit sigiot" produce a core dump would be going a little far, I think.) limit does not append a unit after a zero limit; 0g was too confusing. exec > /nonexistentfile does not cause rc to exit any more. If a noninteractive rc is started with sigint ignored, rc does not install its own signal handler. error messages produced by rc in a subshell were cleaned up. (rc erroneously reset the 'interactive' flag after a fork) print.c was cleaned up a little; no functionality was changed, but should be more portable now. a bug in rc-1.3beta (not previous versions) was fixed: setting the first element of $path to '' caused PATH to be exported as '':etc.. getopt's "illegal option" message was gratuitously changed to something less abrupt. some dead code was removed from input.c %term was changed to %token in parse.y; apparently newer yacc's don't grok %term any more. a race condition in the signal handler was fixed. the variable in for() was getting evaluated each time through the loop (e.g., for (`{echo i;date>[1=2]} in 1 2 3)echo $i would print the date three times). This was cleaned up. a redundant fork() was removed from walk.c; this showed up when running a braced command with a redirection in the background. e.g., {a;b}>c& man pages for history and rc were cleaned up by david (thanks). rc set SIGQUIT and SIGTERM to SIG_DFL on background jobs---even when trying to do old-style backgrounding (i.e., don't use process groups, just ignore SIGINT & SIGQUIT & SIGTERM). $0 is now changed to the name of the signal when entering a signal handler. Thus it's possible to write code like fn sigint sigterm sigquit { switch ($0) { case sigint ... case sigterm ... wait with no arguments now prints the pid of any and all children that died with a signal. e.g., ; wait 25321: terminated 25325: terminated as opposed to ; wait terminated An error saving/restoring state in the input stream code would cause rc to exit with the (erroneous) command: eval '|[a' From rc-owner Thu Apr 2 09:45:59 1992 Received: by archone.tamu.edu id <45331>; Thu, 2 Apr 1992 09:42:40 -0600 From: Byron Rakitzis To: rc Subject: bizarre configuration error on the SGI Message-Id: <92Apr2.094240cst.45331@archone.tamu.edu> Date: Thu, 2 Apr 1992 09:42:40 -0600 If you compile rc-1.4beta as-is on the SGI, then globbing will fail under certain peculiar circumstances (for me: globbing in an NFS-mounted directory from a NeXT. NOT from a Sun or another SGI, just a NeXT). After some hair-pulling, I figured out that SGI has two different versions of opendir & friends (!) one for BSD and one for System V. I guess one uses "struct direct" and the other one "struct DIR", though it beats me why they need to have both. So anyway, it turns out that the BSD version is flawed, and that somehow rc was getting compiled with that version instead of the SysV opendir. A little more hunting showed that it's my fault: my config.h sets "NODIRENT" if the macro "host_mips" is defined. Now, I was informed that this macro was probably unique to RISCos machines, but lo and behold, SGI defines it also. So: 1) if you are compiling 1.4beta on an SGI, you need to edit config.h to take out the #ifdef host_mips stuff. 2) if you have a RISCos machine, PLEASE let me know what a unique-to-RISCos preprocessor macro might be. From rc-owner Fri Apr 3 10:12:28 1992 Received: by archone.tamu.edu id <45316>; Fri, 3 Apr 1992 10:06:11 -0600 From: Byron Rakitzis To: rc Subject: does this specify RISCos? Message-Id: <92Apr3.100611cst.45316@archone.tamu.edu> Date: Fri, 3 Apr 1992 10:06:06 -0600 Does anyone with a MIPS-based machine have cpp macros that satisfy these conditions, or do they uniquely specify RISCos? -DMIPSEB -Dhost_mips -DSYSTYPE_BSD43 I am clutching at straws with this one. Most likely RISCos users will have to do the customization by hand. From rc-owner Fri Apr 3 22:31:50 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45317>; Fri, 3 Apr 1992 22:25:55 -0600 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2721>; Fri, 3 Apr 1992 23:25:26 -0500 To: rc@archone.tamu.edu Subject: rc 1.4 beta trip.rc attempts to run /etc/rc Date: Fri, 3 Apr 1992 22:25:21 -0600 From: Chris Siebenmann Message-Id: <92Apr3.232526est.2721@hawkwind.utcs.toronto.edu> Please don't; if you need an absolute path to an executable or script with the execute bits turned off, composit up in /tmp or the current directory. trip.rc will blow up if your /etc/rc is world executable (ours was, because that's how it came from DEC) or if you're running it as root just prior to installing rc as a final check. - cks From rc-owner Sat Apr 4 22:13:37 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45317>; Sat, 4 Apr 1992 22:10:20 -0600 Received: by groucho.cs.psu.edu id <2538>; Sat, 4 Apr 1992 23:08:53 -0500 From: Scott Schwartz To: rc@archone.tamu.edu Subject: -x -n Message-Id: <92Apr4.230853est.2538@groucho.cs.psu.edu> Date: Sat, 4 Apr 1992 22:08:44 -0600 This is wierd: ; rc -x -n fn x {switch($status){case [^'~'^0]*;echo '# status' $status;}} ; ls ls It prints my prompt function, but only once, and without the correct name. One other wierdness... lists print as, e.g., path=((($minpath $miscpath) $nfspath) .) That seems backwards to me. Wouldn't path=($minpath ($miscpath ($nfspath .))) be more aestetic? From rc-owner Sat Apr 4 22:58:27 1992 Received: by archone.tamu.edu id <45317>; Sat, 4 Apr 1992 22:56:13 -0600 From: Byron Rakitzis To: rc, schwartz@groucho.cs.psu.edu Subject: Re: -x -n Message-Id: <92Apr4.225613cst.45317@archone.tamu.edu> Date: Sat, 4 Apr 1992 22:56:05 -0600 Well, the prompt part is your prompt function getting imported from the environment & interpreted by the rc parser. Since this happens only once (and a good thing!) you only see it once. The "wrong name" is just a convenient trick used to munge the environment string into something the parser will recognize. I suppose it is debatable whether rc -n should be interpreting fn prompt at all---I hadn't thought of this up to now and offhand I should say the answer is no. I will fix this. Lists are parsed "backwards" because of yacc. Doing it the other way would consume yacc stack space proportional to the length of the list. Anyone up for writing a recursive-descent parser for rc? (just kidding...) From rc-owner Sun Apr 5 03:58:05 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45317>; Sun, 5 Apr 1992 03:56:11 -0500 Received: by groucho.cs.psu.edu id <2581>; Sun, 5 Apr 1992 04:55:58 -0400 From: Scott Schwartz To: rc@archone.tamu.edu Subject: file completion Message-Id: <92Apr5.045558edt.2581@groucho.cs.psu.edu> Date: Sun, 5 Apr 1992 03:55:49 -0500 In honor of daylight savings time, here's a quick kludge to do csh style file completion in rc. Feeback solicited. *** 1.1 1992/04/05 08:49:55 --- comp.c 1992/04/05 08:47:41 *************** *** 0 **** --- 1,52 ---- + #include "comp.h" + #include + + static int fdunread (int fd, char* buf, SIZE_T len); + + /* read_with_completion -- if a line doesn't end with newline, + try and expand the last item to match things in the filesystem. + this function does it incorrectly, by looking for a whitespace + to delimit the final 'item'. we really should parse the expression + and do completion on the last item computed in that way, and taking + error recovery into account. Sanjeev is writing his dissertation on + an incremental parser --- ask him how to do it. */ + + extern int read_with_completion (int fd, char* buf, SIZE_T len) { + int r, n, i; + List* list; + char* meta; + char* p; + + while (1) { + r = rc_read (fd, buf, len); + if (r <= 0 || buf[r-1] == '\n') + return r; + else { + buf[r] = '*'; /* XXX - caller has to make sure buf is big enough */ + buf[r+1] = 0; + p = strrchr(buf, ' '); + if (p == 0) p = buf; else ++p; + n = r - (p-buf); + meta = ealloc(n+2); + clear(meta, n+2); + meta[n] = 1; + list = glob(word(p, meta)); /* XXX - what to return on failure? */ + fprint (1, " # (%L)\n", list, " "); + efree(meta); + fdunread (fd, buf, r); + } + } + /* NOTREACHED */ + } + + static int fdunread (int fd, char* buf, SIZE_T len) { + int r; + while (len--) { + r = ioctl (fd, TIOCSTI, buf++); + if (r < 0) { + uerror("ioctl/TIOCSTI"); + return r; + } + } + return 0; + } *** 1.1 1992/04/04 20:14:03 --- input.c 1992/04/04 20:16:51 *************** *** 111,117 **** --- 111,121 ---- } else #endif { + #ifdef COMPLETION + long /*ssize_t*/ r = read_with_completion(istack->fd, inbuf + 2, BUFSIZE); + #else long /*ssize_t*/ r = rc_read(istack->fd, inbuf + 2, BUFSIZE); + #endif if (r < 0) { if (errno == EINTR) continue; /* Suppose it was interrupted by a signal */ From rc-owner Sun Apr 5 05:14:18 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <45317>; Sun, 5 Apr 1992 05:12:28 -0500 Received: by doolittle.vetsci.su.oz.au id <49174>; Sun, 5 Apr 1992 20:11:51 +1000 From: John (Convulsed into oblivion from laughter or from fright) Mackin Date: Sun, 5 Apr 1992 05:09:25 -0500 To: The rc Mailing List Subject: Re: file completion In-Reply-To: <92Apr5.045558edt.2581@groucho.cs.psu.edu> Message-ID: <199204052009.20043.rc.baguk@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Scott writes: In honor of daylight savings time, here's a quick kludge to do csh style file completion in rc. `In honor of daylight savings time'?? FILENAME COMPLETION!??!?!!? This _must_ be a four-day-late April Fool's Day message. OK, John. From rc-owner Tue Apr 7 16:24:45 1992 Received: from gatech.edu ([128.61.1.1]) by archone.tamu.edu with SMTP id <45316>; Tue, 7 Apr 1992 16:18:20 -0500 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA00670 for rc@archone.tamu.edu; Tue, 7 Apr 92 17:18:06 EDT Received: from terminus.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA12799; Tue, 7 Apr 92 17:18:05 EDT Received: by terminus.cc.gatech.edu (4.1/SMI-4.1) id AA00942; Tue, 7 Apr 92 17:18:01 EDT From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9204072118.AA00942@terminus.cc.gatech.edu> Date: Tue, 7 Apr 1992 16:18:00 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: rc@archone.tamu.edu Subject: signal blocking? Is there an easy way to block a signal inside a signal handler? I'm using MGR from BellCore (fast!), and I've been trying to set up a signal handler for SIGWINCH so that the rows and columns in stty get reset whenever I resize a window. However, when you do an stty of the rows and columns, MGR kindly sends you another SIGWINCH too! So I need to temporarily block SIGWINCH (ignore it basically) inside my SIGWINCH handler. Here's what I ended up doing. Simple, but not terribly elegant. Note that the trailing sleep is needed or else the SIGWINCH comes in before we're ready. fn handle_winch { size=() { fn sigwinch # temporary stty -echo echo '4I' size=(`{gawk '{ printf "%d %d\n", $3/12, $4/20 ; exit }'}) stty echo stty columns $size(1) rows $size(2) sleep 1 fn sigwinch { handle_winch } } } fn sigwinch { handle_winch } -- Arnold Robbins --- College of Computing | Laundry increases Georgia Tech, Atlanta, GA 30332-0280 | exponentially in the Domain: arnold@cc.gatech.edu Phone: +1 404 894 9214 | number of children. UUCP: uunet!cc.gatech.edu!arnold FAX: +1 404 853 9378 | -- Miriam Robbins From rc-owner Tue Apr 7 17:16:00 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45318>; Tue, 7 Apr 1992 17:12:59 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Tue, 7 Apr 1992 18:12:35 -0400 To: arnold@cc.gatech.edu (Arnold Robbins) cc: rc@archone.tamu.edu Subject: Re: signal blocking? In-reply-to: Your message of "Tue, 07 Apr 92 17:18:00 EDT." <9204072118.AA00942@terminus.cc.gatech.edu> Date: Tue, 7 Apr 1992 17:12:20 -0500 From: schwartz@groucho.cs.psu.edu Message-Id: <92Apr7.181235edt.2538@groucho.cs.psu.edu> | I'm using MGR from BellCore (fast!), Yeah, MGR is neat... everyone should check it out. | So I need to temporarily block | SIGWINCH (ignore it basically) inside my SIGWINCH handler. fn sigfoo {} should set SIGFOO to SIG_IGN. Will that do it for you? I notice that if I write ; fn sigwinch { stty } and then resize my xterm, rc exits fdgchar with ``read: No such file or directory''. (This is on a Sun4 under SunOS 4.1.1.) From rc-owner Tue Apr 7 17:24:57 1992 Received: from gatech.edu ([128.61.1.1]) by archone.tamu.edu with SMTP id <45319>; Tue, 7 Apr 1992 17:22:48 -0500 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA01599 for rc@archone.tamu.edu; Tue, 7 Apr 92 18:22:28 EDT Received: from terminus.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA15211; Tue, 7 Apr 92 18:22:23 EDT Received: by terminus.cc.gatech.edu (4.1/SMI-4.1) id AA02228; Tue, 7 Apr 92 18:22:17 EDT From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9204072222.AA02228@terminus.cc.gatech.edu> Date: Tue, 7 Apr 1992 17:22:16 -0500 In-Reply-To: schwartz@groucho.cs.psu.edu's 36-line message on Apr 7, 6:12pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: schwartz@groucho.cs.psu.edu Subject: Re: signal blocking? Cc: rc@archone.tamu.edu > To: arnold@cc.gatech.edu (Arnold Robbins) > Cc: rc@archone.tamu.edu > Subject: Re: signal blocking? > Date: Tue, 7 Apr 1992 18:12:20 -0400 > From: schwartz@groucho.cs.psu.edu > > | So I need to temporarily block > | SIGWINCH (ignore it basically) inside my SIGWINCH handler. > > fn sigfoo {} should set SIGFOO to SIG_IGN. Will that do it for you? No, since I need to do it inside the handler for SIGFOO... > I notice that if I write > > ; fn sigwinch { stty } > > and then resize my xterm, rc exits fdgchar with ``read: No such file or > directory''. > > (This is on a Sun4 under SunOS 4.1.1.) This is the result I was getting, although I didn't know where in rc it was coming from; that's why I added the sleep. Arnold From rc-owner Tue Apr 7 17:28:55 1992 Received: from gatech.edu ([128.61.1.1]) by archone.tamu.edu with SMTP id <45320>; Tue, 7 Apr 1992 17:25:54 -0500 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA01671 for rc@archone.tamu.edu; Tue, 7 Apr 92 18:25:19 EDT Received: from terminus.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA15250; Tue, 7 Apr 92 18:25:15 EDT Received: by terminus.cc.gatech.edu (4.1/SMI-4.1) id AA02290; Tue, 7 Apr 92 18:25:10 EDT From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9204072225.AA02290@terminus.cc.gatech.edu> Date: Tue, 7 Apr 1992 17:25:09 -0500 In-Reply-To: schwartz@groucho.cs.psu.edu's 37-line message on Apr 7, 5:12pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: schwartz@groucho.cs.psu.edu Subject: Re: signal blocking? Cc: rc@archone.tamu.edu Get this. The function works ok with the version of rc linked with the readline library, and bombs on the version without it. Sigh. Arnold From rc-owner Tue Apr 7 18:28:19 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45321>; Tue, 7 Apr 1992 18:25:25 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Tue, 7 Apr 1992 19:25:02 -0400 To: arnold@cc.gatech.edu (Arnold Robbins) cc: rc@archone.tamu.edu Subject: Re: signal blocking? In-reply-to: Your message of "Tue, 07 Apr 92 18:25:09 EDT." <9204072225.AA02290@terminus.cc.gatech.edu> Date: Tue, 7 Apr 1992 18:24:45 -0500 From: schwartz@groucho.cs.psu.edu Message-Id: <92Apr7.192502edt.2538@groucho.cs.psu.edu> | Get this. The function works ok with the version of rc linked with | the readline library, and bombs on the version without it. Sigh. That's because readline ignores the return code from read(), while Byron carefully checks it. From rc-owner Tue Apr 7 18:33:08 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45322>; Tue, 7 Apr 1992 18:30:21 -0500 Received: by groucho.cs.psu.edu id <2538>; Tue, 7 Apr 1992 19:30:04 -0400 From: Scott Schwartz To: rc@archone.tamu.edu Subject: more sigwinch Message-Id: <92Apr7.193004edt.2538@groucho.cs.psu.edu> Date: Tue, 7 Apr 1992 18:29:53 -0500 Another case: ; fn sigwinch { stty ; return 0 } ; speed 9600 baud; evenp susp ; dsusp -inpck ixany imaxbel iexten crt return outside of function # status 1 No shell-death this time, though. From rc-owner Tue Apr 7 20:58:49 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45323>; Tue, 7 Apr 1992 20:53:06 -0500 Received: by groucho.cs.psu.edu id <2538>; Tue, 7 Apr 1992 21:52:39 -0400 From: Scott Schwartz To: rc@archone.tamu.edu Subject: Reentrant runtime systems considered long overdue (sigwinch bug) Message-Id: <92Apr7.215239edt.2538@groucho.cs.psu.edu> Date: Tue, 7 Apr 1992 20:52:38 -0500 Signals are evil. It looks like the sigwinch thing is going wrong because, by the time rc_read returns in fdgchar, errno has been altered by a system call---stat in this case. Hence the check for errno==EINTR never works out, and bad things happen. The error "No such file or directory" isn't something read can return. That's a clue to the real source of the error, which is the stat call in rc_access, called inside the interrupt handler when it tries to run e.g. stty and has to check a number of entries in your path. That stat call is (in this instance) the last time errno gets set before the longjmp out of the read in rc_read. Tossing an errno=EINTR after the stat mitigates the problem. -- Scott From rc-owner Tue Apr 7 21:06:21 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <45324>; Tue, 7 Apr 1992 20:58:54 -0500 Received: by doolittle.vetsci.su.oz.au id <49182>; Wed, 8 Apr 1992 11:55:45 +1000 From: John (Convulsed into oblivion from laughter or from fright) Mackin Date: Tue, 7 Apr 1992 20:37:36 -0500 To: The rc Mailing List Subject: Re: signal blocking? In-Reply-To: <9204072118.AA00942@terminus.cc.gatech.edu> Message-ID: <199204081137.11799.rc.baguv@vetsci.su.oz.au> References: <91Dec18.230318cst.18887@archone.tamu.edu> <199201222335.28010.rc.badaj@vetsci.su.oz.au> <92Jan28.114835cst.18891@archone.tamu.edu> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Arnold asked: Is there an easy way to block a signal inside a signal handler? Without in any way endorsing the use it's proposed to put this facility to, I'd like to point out, firstly, that I don't believe there is anything substantially easier or cleaner that what you already did (although the first quote from Byron below shows an elegant twist), and secondly, that rc should block them for you. I don't know how `real' Byron will think this application is; what about it, Byron? The remainder of this message is quoted from three mail items: from Byron to me, my reply, and his reply to that. OK, John. From: Byron Rakitzis Date: Thu, 19 Dec 1991 16:03:06 +1100 To: john@vetsci.su.oz.au Subject: Re: editable terminal for X Message-Id: <91Dec18.230318cst.18887@archone.tamu.edu> [...] I am not sure what to do about high-level [signal] semantics, though. What if you get an interrupt inside a user-defined interrupt handler? I am assuming that an rc user will have to explicitly mask interrupts with something like: fn sigint savesigint { fn sigint ... code ... eval `{whatis savesigint | sed 's/fn /fn sigint/'} } Does that look reasonable? (I just came up with that solution by the way; I haven't thought about the high-level stuff much) What are the other alternatives? I have never used signal handlers in a shell for anything "real" so I cannot imagine a "real" use for them where it would matter one way or another whether signals are trapped inside them. [...] From: John (I've got some bad news for you, sunshine) Mackin Date: Wed, 22 Jan 1992 23:35:55 +1100 To: Byron Rakitzis Subject: high-level signal semantics (was Re: editable terminal for X) Message-ID: <199201222335.28010.rc.badaj@vetsci.su.oz.au> [...] Does that look reasonable? [...] It actually doesn't look that reasonable to me. I don't use signal handlers for anything `real' ever if I can avoid it, but I think that the above is not the way to go. That's giving the handlers semantics rather like those of Seventh Edition signals. Now, most things about Seventh Edition are just right, but in fact one way BSD did better is (in some facets) with signals. We are much better off with BSD signal semantics at the high (user handler function) level. They are that the handler for signal S will never be called recursively by the signal mechanism. So in the above, once you're inside fn sigint, a further interrupt will be queued and result in fn sigint being called again only after it returns. Signal S' in no way affects signal S: different signals should interrupt each other's handlers, it is only that the _same_ signal should never interrupt its _own_ handler. Those are definitely the best semantics for signal handlers to have. OK, John. From: Byron Rakitzis Date: Wed, 29 Jan 1992 04:48:34 +1100 To: john@vetsci.su.oz.au Subject: signal handlers Message-Id: <92Jan28.114835cst.18891@archone.tamu.edu> You argued for BSD signal semantics in rc signal handlers. All I want to know is, is it worth the effort? Also, what happens if you do: fn sigint { sleep 10 ... ... } is it the "right thing" that that sleep should be uninterruptible? Right now I'm just taking the easy way out. I'm not saying that's a good thing, but it will take some persuasion + real life examples to tell me that the present signal handling semantics are inadequate. From rc-owner Wed Apr 8 08:27:55 1992 Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by archone.tamu.edu with SMTP id <45325>; Wed, 8 Apr 1992 08:24:35 -0500 Received: by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5-ins) id AA26765; Wed, 8 Apr 92 09:21:26 -0400 (from chet for rc@archone.tamu.edu) Date: Wed, 8 Apr 1992 08:18:30 -0500 From: Chet Ramey To: schwartz@groucho.cs.psu.edu Subject: Re: signal blocking? Cc: arnold@cc.gatech.edu, rc@archone.tamu.edu, chet@odin.INS.CWRU.Edu Reply-To: chet@po.CWRU.Edu In-Reply-To: Message from schwartz@groucho.cs.psu.edu of Tue, 7 Apr 1992 18:24:45 -0500 Message-Id: <9204081318.AA26738.SM@odin.INS.CWRU.Edu> Read-Receipt-To: chet@po.CWRU.Edu > | Get this. The function works ok with the version of rc linked with > | the readline library, and bombs on the version without it. Sigh. > > That's because readline ignores the return code from read(), while > Byron carefully checks it. Oh, please, give me a break. Why not check these things out before shooting from the hip? >From rl_getc: result = read (fileno (stream), &c, sizeof (unsigned char)); if (result == sizeof (unsigned char)) return (c); /* If zero characters are returned, then the file that we are reading from is empty! Return EOF in that case. */ if (result == 0) return (EOF); ... and so on ... Chet -- ``The use of history as therapy means the corruption of history as history.'' -- Arthur Schlesinger Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu From rc-owner Wed Apr 8 10:54:16 1992 Received: by archone.tamu.edu id <45326>; Wed, 8 Apr 1992 10:49:08 -0500 From: Byron Rakitzis To: rc Subject: Re: signal blocking? Message-Id: <92Apr8.104908cdt.45326@archone.tamu.edu> Date: Wed, 8 Apr 1992 10:49:02 -0500 Ok, it seems this application of signal handlers is as "real" as they get. re: putting a "return" in the signal handler. This is not going to do a lot of good, since setting $status never changes the value of errno in any case. I have specifically made signal handler invocations different from function invocations (no "return" is allowed) so that one could realize that it is not a very meaningful thing to set $status in a signal handler. It seems that the fundamental limitation here is not the ability of rc to queue signals inside a signal handler, but rather the system call/errno interface. read() returns a -1 on failure---any kind of failure---and then you have to check errno to see what the error really was. When a signal handler buggers the value of errno you are really done for. Therefore my initial reaction would be to have a signal handler do a save/restore of errno, and preserve the v7 semantics of rc signal handlers; I don't really feel like changing the way signals are done in rc right now. It still seems like too much work, and the current problem can be solved with this code: ; fn sigwinch {handle} ; fn handle { fn sigwinch stty fn sigwinch {handle} } (I just tried this on a NeXT and a Sun, with a save/restore of errno in fn_handler, and a window-size-change on a terminal window) Anyway, here's a context diff for fn.c: *** fn.c.orig Sun Mar 29 10:32:36 1992 --- fn.c Wed Apr 8 10:39:35 1992 *************** *** 4,9 **** --- 4,10 ---- */ #include + #include #include "rc.h" #include "sigmsgs.h" *************** *** 84,91 **** --- 85,94 ---- static void fn_handler(int s) { List *dollarzero; Estack e; + int olderrno; if (s < 1 || s >= NUMOFSIGNALS) panic("unknown signal"); + olderrno = errno; dollarzero = nnew(List); dollarzero->w = signals[s][0]; dollarzero->n = NULL; *************** *** 94,99 **** --- 97,103 ---- walk(handlers[s], TRUE); varrm("*", TRUE); unexcept(); /* eVarstack */ + errno = olderrno; } /* From rc-owner Wed Apr 8 13:39:46 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45328>; Wed, 8 Apr 1992 13:34:00 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2581>; Wed, 8 Apr 1992 14:33:37 -0400 To: chet@po.CWRU.Edu cc: schwartz@groucho.cs.psu.edu, arnold@cc.gatech.edu, rc@archone.tamu.edu, chet@odin.INS.CWRU.Edu Subject: Re: signal blocking? In-reply-to: Your message of "Wed, 08 Apr 92 09:18:30 EDT." <9204081318.AA26738.SM@odin.INS.CWRU.Edu> Date: Wed, 8 Apr 1992 13:33:29 -0500 From: schwartz@groucho.cs.psu.edu Message-Id: <92Apr8.143337edt.2581@groucho.cs.psu.edu> | Oh, please, give me a break. Why not check these things out before | shooting from the hip? Hey, take it easy. Actually, I did check; unfortunately it was the editline source I looked at. Honest mistake, ok? From rc-owner Thu Apr 9 19:13:04 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45327>; Thu, 9 Apr 1992 19:07:32 -0500 Received: by groucho.cs.psu.edu id <2538>; Thu, 9 Apr 1992 20:06:44 -0400 From: Scott Schwartz To: rc@archone.tamu.edu Subject: eval vs & Message-Id: <92Apr9.200644edt.2538@groucho.cs.psu.edu> Date: Thu, 9 Apr 1992 19:06:34 -0500 Consider this: ; x='sleep 3' ; eval $x & 16105 ; x='sleep 3 &' ; eval $x ; # No pid? /bin/sh would print the pid. (Speaking of asynchronous processes, I kind of miss getting exit notification and being able to find out what their exit status is ala csh. It's not as if rc isn't doing the wait() already. Maybe when file completion is done.... :-)) From rc-owner Thu Apr 9 19:22:16 1992 Received: by archone.tamu.edu id <45334>; Thu, 9 Apr 1992 19:19:43 -0500 From: Byron Rakitzis To: rc Subject: Re: eval vs & Message-Id: <92Apr9.191943cdt.45334@archone.tamu.edu> Date: Thu, 9 Apr 1992 19:19:36 -0500 re: eval and &. Well, input for eval is rescanned noninteractively, so interactive features get lost during an eval. This is perhaps bogomorphic. At the same time, however, you don't want rc to print prompts while it chugs through an eval. re: wait(). rc does not trap SIGCLD, so it cannot notify you asynchronously of a child's death. This may be another bogomorphism, but so far I've been using Occam's razor, i.e., avoiding complexity in the design whenever possible. From rc-owner Thu Apr 9 19:39:29 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45335>; Thu, 9 Apr 1992 19:36:17 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Thu, 9 Apr 1992 20:35:47 -0400 To: Byron Rakitzis cc: rc@archone.tamu.edu Subject: Re: eval vs & In-reply-to: Your message of "Thu, 09 Apr 92 20:19:36 EDT." <92Apr9.191943cdt.45334@archone.tamu.edu> Date: Thu, 9 Apr 1992 19:35:37 -0500 From: schwartz@groucho.cs.psu.edu Message-Id: <92Apr9.203547edt.2538@groucho.cs.psu.edu> | re: eval and &. Well, input for eval is rescanned noninteractively, | so interactive features get lost during an eval. This is perhaps | bogomorphic. At the same time, however, you don't want rc to print | prompts while it chugs through an eval. I suppose. But it surprised me while using ``--'', just now. | re: wait(). rc does not trap SIGCLD, so it cannot notify you | asynchronously of a child's death. This may be another bogomorphism, | but so far I've been using Occam's razor, i.e., avoiding complexity | in the design whenever possible. Actually async notification is not really what I had in mind. I was thinking that when rc does happen to wait(), it could collect all the statuses and put them in $astatus. The the prompt function could print them if you wanted them. From rc-owner Sat Apr 11 18:14:10 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45316>; Sat, 11 Apr 1992 18:09:50 -0500 Received: by groucho.cs.psu.edu id <2603>; Sat, 11 Apr 1992 19:09:32 -0400 From: Scott Schwartz To: rc@archone.tamu.edu Subject: more ile stuff Message-Id: <92Apr11.190932edt.2603@groucho.cs.psu.edu> Date: Sat, 11 Apr 1992 18:09:25 -0500 What do you all think of this change to ile's irupt()? In some cases it makes interrupts seem cleaner. irupt(c) char c; { int zero = 0; erase_line(c); pass(c); if (ioctl (1, TIOCFLUSH, &zero) < 0) perror("ioctl/flush"); } From rc-owner Thu Apr 16 17:17:04 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45316>; Thu, 16 Apr 1992 17:12:18 -0500 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2714>; Thu, 16 Apr 1992 18:12:03 -0400 To: rc@archone.tamu.edu Subject: today's rc programming challenge Date: Thu, 16 Apr 1992 17:11:48 -0500 From: Chris Siebenmann Message-Id: <92Apr16.181203edt.2714@hawkwind.utcs.toronto.edu> Given: a string in a variable. Wanted: the same string but without the newline on the end Challenge: how, in the (possible) presence of any character except binary 0 in the string, do to this? Bonus points awarded for the shortest solution, the most efficient solution, and one that can be stuck in a function. - cks From rc-owner Fri Apr 17 07:09:37 1992 Received: from piggy.ucsb.edu ([128.111.72.50]) by archone.tamu.edu with SMTP id <45319>; Fri, 17 Apr 1992 07:07:25 -0500 Return-Path: Received: from localhost.ucsb.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA12185; Fri, 17 Apr 92 05:07:06 -0700 Message-Id: <9204171207.AA12185@piggy.ucsb.edu> To: Chris Siebenmann Cc: rc@archone.tamu.edu Subject: Re: today's rc programming challenge In-Reply-To: Your message of "Thu, 16 Apr 92 17:11:48 CDT." <92Apr16.181203edt.2714@hawkwind.utcs.toronto.edu> Date: Fri, 17 Apr 1992 06:07:00 -0500 From: Robert Earl fn chop { l=() { for (f in ``$nl{whatis $1}) { ~ $#l 0 || echo -n $l ~ $f '''' && {echo ''''; return} ~ $#l 0 || echo l=$f } } } you call it with a variable name rather than the value; and it prints a variable assignment a la `whatis' on stdout, so to use it: ; foo='testing chop. ' ; eval ``(){chop foo} and foo is now chopped. i know the calling syntax is obscure, but using whatis was convenient - it knows how to quote, and in the presence of tabs and spaces, echo could get things wrong. OBChallenge: make this work with more than one argument. i had to use "return" to cut out of the loop (which is why it HAS to be in a function). From rc-owner Fri Apr 17 08:25:42 1992 Received: from postman.osf.org ([130.105.1.152]) by archone.tamu.edu with SMTP id <45320>; Fri, 17 Apr 1992 08:24:12 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA17446; Fri, 17 Apr 92 09:23:52 -0400 Received: by earth.osf.org (5.64/4.7) id AA02784; Fri, 17 Apr 92 09:23:51 -0400 Date: Fri, 17 Apr 1992 08:23:51 -0500 From: rsalz@osf.org Message-Id: <9204171323.AA02784@earth.osf.org> To: chupchup@piggy.ucsb.edu, cks@hawkwind.utcs.toronto.edu Subject: Re: today's rc programming challenge Cc: rc@archone.tamu.edu I tried your function and got my trailing ` missing. What's wrong with builtin echo -n ? From rc-owner Fri Apr 17 09:06:00 1992 Received: from harvard.harvard.edu ([128.103.1.1]) by archone.tamu.edu with SMTP id <45321>; Fri, 17 Apr 1992 09:04:31 -0500 Received: by harvard.harvard.edu (5.54/a0.25) (for rc@archone.tamu.edu) id AA17332; Fri, 17 Apr 92 09:04:17 EST Received: from gatech.UUCP (uucp.gatech.edu) by gatech.edu (4.1/Gatech-9.1) id AA28315 for archone.tamu.edu!rc; Fri, 17 Apr 92 09:55:48 EDT Received: from skeeve.UUCP by gatech.UUCP (4.1/SMI-4.1) id AA20850; Fri, 17 Apr 92 09:03:31 EDT Received: by skeeve.ATL.GA.US (smail2.5) id AA11086; 17 Apr 92 07:34:15 EST (Fri) From: gatech!skeeve!arnold@harvard.harvard.edu (Arnold D. Robbins) Date: Fri, 17 Apr 1992 07:34:13 -0500 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: Chris Siebenmann Subject: Re: today's rc programming challenge Cc: rc@archone.tamu.edu Message-Id: <9204170734.AA11086@skeeve.ATL.GA.US> > Given: a string in a variable. > Wanted: the same string but without the newline on the end > > Challenge: how, in the (possible) presence of any character except binary > 0 in the string, do to this? Bonus points awarded for the shortest solution, > the most efficient solution, and one that can be stuck in a function. x='foo ' x=`{tr -d ' ' <<< $x} fn stripnl { ret=() { ret=`{tr -d ' ' <<< $1 return ret }} Arnold From rc-owner Fri Apr 17 16:09:51 1992 Received: from harvard.harvard.edu ([128.103.1.1]) by archone.tamu.edu with SMTP id <45322>; Fri, 17 Apr 1992 16:06:53 -0500 Received: by harvard.harvard.edu (5.54/a0.25) (for rc@archone.tamu.edu) id AA25458; Fri, 17 Apr 92 16:06:40 EST Received: from gatech.UUCP (uucp.gatech.edu) by gatech.edu (4.1/Gatech-9.1) id AA04811 for archone.tamu.edu!rc; Fri, 17 Apr 92 16:54:58 EDT Received: from skeeve.UUCP by gatech.UUCP (4.1/SMI-4.1) id AA03328; Fri, 17 Apr 92 16:02:41 EDT Received: by skeeve.ATL.GA.US (smail2.5) id AA11278; 17 Apr 92 13:18:21 EST (Fri) To: rc@archone.tamu.edu Subject: trailing newlines Message-Id: <9204171318.AA11278@skeeve.ATL.GA.US> Date: Fri, 17 Apr 1992 13:18:21 -0500 From: gatech!skeeve!arnold@harvard.harvard.edu (Arnold D. Robbins) OK, here's another try, (tested, even!): x = ' string with lots of embedded newlines ' gawk ' { if (! first) print save else first = 1 save = $0 } END { printf ("%s", save) }' <<< $x Your luck with other awks may vary, particularly when processing binary data; I have much higher confidence in gawk in that regard. Arnold From rc-owner Fri Apr 17 17:23:17 1992 Received: from relay1.UU.NET ([137.39.1.5]) by archone.tamu.edu with SMTP id <45323>; Fri, 17 Apr 1992 17:19:24 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17804; Fri, 17 Apr 92 18:19:08 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 181858.6158; Fri, 17 Apr 1992 18:18:58 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa11496; Fri, 17 Apr 92 17:54:43 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@archone.tamu.edu Subject: rc and readline and SIGINT Date: Fri, 17 Apr 1992 16:52:51 -0500 Message-Id: <9204171752.aa00070@ceres.srg.af.mil> Well, I'm going to throw this one open to everyone and maybe someone like Chet will read it and come up with a good answer. Under rc-1.2 with or without readline if I hit the key for SIGINT it aborted the current input line. This was good and righteous and all that. Under rc-1.3 with readline it no longer seemed to work right. Since 1.3 had signal handling (and other) problems it was hard to be sure what the trouble was. Under rc-1.4beta without readline SIGINT works as expected/desired and aborts the line. With readline the line doesn't get executed, but it doesn't get cleared or quit either and further input is accepted but not executed. Furthermore if signal handling in readline is disabled the key loses it's meaning as SIGINT! (This is strictly readlines "fault") While I can live with this, it is rather unaesthetic and just plain bugs me. Any clues? Tom From rc-owner Sat Apr 18 10:08:15 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by archone.tamu.edu with SMTP id <45324>; Sat, 18 Apr 1992 10:05:59 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA10282; Sat, 18 Apr 92 17:05:50 +0200 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA03196; Sat, 18 Apr 92 17:05:24 +0200 Date: Sat, 18 Apr 1992 10:05:24 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9204181505.AA03196@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: Re: trailing newlines I'm not sure if I get the point, but isn't this what you want: x = `` ($nl) { echo $x } # strips all newlines or fn deletenl { * = `` ($nl) { echo $* } while ( ! ~ $#* 0 1 ){ # echo all args but the last echo $^1 shift } echo -n `` ($nl) { echo $^1 } # echo last arg without nl } x = `` () { deletenl $x } To be honest, deletenl squeezes repeated nls into one. Malte. From rc-owner Sat Apr 18 17:47:34 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45325>; Sat, 18 Apr 1992 17:45:23 -0500 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2715>; Sat, 18 Apr 1992 18:45:00 -0400 To: rc@archone.tamu.edu Subject: My programming challenge: the motivation Date: Sat, 18 Apr 1992 17:44:46 -0500 From: Chris Siebenmann Message-Id: <92Apr18.184500edt.2715@hawkwind.utcs.toronto.edu> I neglected to write out in full that newlines are allowed in the string, and that all such newlines *must* be preserved. The motivation for this exercise is to write code that can correctly handle *all* filenames it may get handed, and manipulate the result. Consider, for example, handing a loop of the form: for (i in $*) { x=`{basename $i .blorf} ... } a filename that has a newline in it. We can get the 'full' name back from basename with x=`` () {basename $i .blorf} but it will have an extraneous trailing newline on the end; we need to be able to strip this off, while leaving everything else untouched. And there's the problem. - cks From rc-owner Sun Apr 19 19:50:50 1992 Received: from andrew.cmu.edu ([128.2.11.131]) by archone.tamu.edu with SMTP id <45316>; Sun, 19 Apr 1992 19:47:11 -0500 Received: by andrew.cmu.edu (5.54/3.15) id for rc@archone.tamu.edu; Sun, 19 Apr 92 20:46:56 EDT Received: via switchmail; Sun, 19 Apr 1992 20:46:55 -0400 (EDT) Received: from elementary.bh.andrew.cmu.edu via qmail ID ; Sun, 19 Apr 1992 20:46:12 -0400 (EDT) Received: via niftymail; Sun, 19 Apr 1992 20:46:02 -0400 (EDT) Date: Sun, 19 Apr 1992 19:46:02 -0500 From: "Julian L. Ho" Subject: jobs list To: rc@archone.tamu.edu Message-Id: <703730762.2950.0@elementary.bh.andrew.cmu.edu> I've been using "echo $apids" and "ps pid" a lot recently, so I wrote this. I don't know if I like it yet... -J fn jobs { if (! ~ $#* 0) { # list commands with current tty ps guxwwt ^ `{ tty | sed 's/.*\(..\)$/\1/' } return } if (~ $#apids 0) return # list $apids pat = ( '$2 == ' ^ $apids ^ ' ||' ) { pat = $^pat ^ 'NR == 1' ps guxww | awk $pat } } From rc-owner Mon Apr 20 09:25:13 1992 Received: from eros.uknet.ac.uk ([192.91.199.2]) by archone.tamu.edu with SMTP id <45319>; Mon, 20 Apr 1992 09:19:57 -0500 Received: from ibmpcug.co.uk by eros.uknet.ac.uk with UUCP id <20000-0@eros.uknet.ac.uk>; Mon, 20 Apr 1992 11:34:37 +0100 X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. Newsgroups: list.rc In-Reply-To: <703730762.2950.0@elementary.bh.andrew.cmu.edu> Organization: The IBM PC User Group, UK. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: rc@archone.tamu.edu Subject: Re: jobs list Date: Mon, 20 Apr 1992 04:19:31 -0500 From: Matthew Farwell Sender: dylan@ibmpcug.co.uk Message-ID: <9204201019.aa14391@kate.ibmpcug.co.uk> In article <703730762.2950.0@elementary.bh.andrew.cmu.edu> you write: >I've been using "echo $apids" and "ps pid" a lot recently, so I wrote >this. I don't know if I like it yet... > [ deleted ] Course, if you had a sensible ps..... Script started on Mon Apr 20 10:16:37 1992 ; sleep 3600 & sleep 3600 & sleep 3600 & 14342 14343 14344 ; echo $apids 14342 14343 14344 ; ps -fp,^$apids UID PID PPID C STIME TTY TIME COMMAND dylan 14342 14341 0 10:16:45 p0 0:00 sleep 3600 dylan 14343 14341 0 10:16:49 p0 0:00 sleep 3600 dylan 14344 14341 0 10:16:53 p0 0:00 sleep 3600 ; script done on Mon Apr 20 10:17:13 1992 Dylan. -- "It's at times like this I wish I'd listened to what my mother used to say" "Why, what did she say?" "I don't know - I never listened." From rc-owner Tue Apr 21 18:23:57 1992 Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by archone.tamu.edu with SMTP id <45321>; Tue, 21 Apr 1992 18:17:56 -0500 Received: by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5-ins) id AA12422; Tue, 21 Apr 92 15:15:16 -0400 (from chet for /usr/homes/chet/bin/mailfilter.sh /usr/homes/chet/mbox) Date: Tue, 21 Apr 1992 13:36:44 -0500 From: Chet Ramey To: culliton@srg.af.mil Subject: Re: rc and readline and SIGINT Cc: rc@archone.tamu.edu, chet@odin.INS.CWRU.Edu Reply-To: chet@po.CWRU.Edu In-Reply-To: Message from culliton@srg.af.mil of Fri, 17 Apr 1992 16:52:51 -0500 Message-Id: <9204211836.AA11917.SM@odin.INS.CWRU.Edu> Read-Receipt-To: chet@po.CWRU.Edu > Well, I'm going to throw this one open to everyone and maybe someone like > Chet will read it and come up with a good answer. OK, here goes. rc and bash manage signals very similarly. The regular signal handler simply sets a flag noting that the signal occurred, and the handler is run when it is convenient to do so. So far, so good. Readline saves the old SIGINT signal handler, restores it, and sends another SIGINT to itself after restoring it. Any application-specific SIGINT handling should still take place. Bash, however, has a hook, in the form of a flag, that different parts of the code can set to tell the signal handler to interrupt immediately rather than simply setting a flag. The code that calls readline uses this to longjmp back to the top level when readline re-sends the SIGINT to the shell. The problem is that readline assumes that if the signal handler returns, after it resends the SIGINT and clears the signal mask so it will get through, it is to go on. It is the application's responsibility to handle SIGINT however it likes -- readline should be perfectly happy if you want to ignore SIGINT when you call it. rc just sets the flag and lets readline continue. Readline reads until a newline and returns the line. At that point, rc finally notices that SIGINT was caught and longjmps back to the top level. > Furthermore if signal handling in readline is disabled > the key loses it's meaning as SIGINT! (This is strictly readlines > "fault") It's probably not a good idea to build readline with HANDLE_SIGNALS undefined. Readline disables ISIG if it's not defined. It has to be able to clean up after itself, and especially to restore the terminal to a sane state. Chet > > While I can live with this, it is rather unaesthetic and just plain > bugs me. Any clues? > > Tom > > -- ``The use of history as therapy means the corruption of history as history.'' -- Arthur Schlesinger Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu From rc-owner Fri Apr 24 19:22:09 1992 Received: from relay1.UU.NET ([137.39.1.5]) by archone.tamu.edu with SMTP id <45321>; Fri, 24 Apr 1992 19:17:11 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28792; Fri, 24 Apr 92 20:16:45 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 201312.3836; Fri, 24 Apr 1992 20:13:12 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa09002; Fri, 24 Apr 92 17:49:13 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@archone.tamu.edu Subject: Re: rc and readline and SIGINT Date: Fri, 24 Apr 1992 16:46:31 -0500 Message-Id: <9204241746.aa01849@ceres.srg.af.mil> Well this is the first chance I've had to really take a good look at what Chet had to say on the topic and relate it to the the rc code. >From looking at signal.c, util.c, and wait.c it looks like the problem would be easily solved by treating readline as a "slow" system call. Before I plunge into this, can anybody think of reasons that this would be a bad idea? Byron? Tom From rc-owner Fri Apr 24 20:38:15 1992 Received: from po5.andrew.cmu.edu ([128.2.10.105]) by archone.tamu.edu with SMTP id <45316>; Fri, 24 Apr 1992 20:33:45 -0500 Received: by po5.andrew.cmu.edu (5.54/3.15) id for rc@archone.tamu.edu; Fri, 24 Apr 92 21:33:29 EDT Received: via switchmail; Fri, 24 Apr 1992 21:33:27 -0400 (EDT) Received: from mcdivitt.res.andrew.cmu.edu via qmail ID ; Fri, 24 Apr 1992 21:32:32 -0400 (EDT) Received: from mcdivitt.res.andrew.cmu.edu via qmail ID ; Fri, 24 Apr 1992 21:32:10 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.mcdivitt.res.andrew.cmu.edu.pmax.ul4 via MS.5.6.mcdivitt.res.andrew.cmu.edu.pmax_ul4; Fri, 24 Apr 1992 21:32:10 -0400 (EDT) Message-Id: Date: Fri, 24 Apr 1992 20:32:10 -0500 From: "Josh N. Pritikin" To: rc@archone.tamu.edu Subject: file protections In-Reply-To: <9204241746.aa01849@ceres.srg.af.mil> References: <9204241746.aa01849@ceres.srg.af.mil> Beak: Is not. At CMU we use AFS a great deal. I've run into was seems to be a bad interaction between AFS and rc. Consider this program: $ C:/inc/graphlib>ll glclock -rwx------ 1 14061 0 319488 Apr 24 18:22 glclock* I log into the CS cell get my tokens with klog so I have access to this program in the Andrew cell. Thus, even though I don't own the file or have access to it via the rwx flags, I should be able to run it, however, C:/inc/graphlib>./glclock ./glclock: Permission denied [status 1] Now if I, C:/inc/graphlib>sh $ ./glclock It works fine. Is this fixable without special casing for AFS? joshp From rc-owner Sun Apr 26 13:14:37 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45319>; Sun, 26 Apr 1992 13:11:44 -0500 Received: by groucho.cs.psu.edu id <2538>; Sun, 26 Apr 1992 14:10:43 -0400 From: Scott Schwartz To: rc@archone.tamu.edu Subject: pgrp? Message-Id: <92Apr26.141043edt.2538@groucho.cs.psu.edu> Date: Sun, 26 Apr 1992 13:10:40 -0500 Should rc take care that the tty is in the proper process group after a child exits? ; rc ; newpgrp ; exit rc_read: I/O error # first shell dies here From rc-owner Thu Apr 30 14:56:00 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by archone.tamu.edu with SMTP id <45316>; Thu, 30 Apr 1992 14:51:48 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA03639; Thu, 30 Apr 92 21:51:26 +0200 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA22003; Thu, 30 Apr 92 21:50:48 +0200 Date: Thu, 30 Apr 1992 14:50:48 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9204301950.AA22003@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: possible memory leak in rc-1.4b Hi, I have just finished a first attempt to port rc-1.4 to Minix (Atari ST). It runs perfect with only one exeption: Minix lacks virtual memory, so every process runs in a fixed size segment (of physical memory). After a period of time rc runs out of memory. This period seems to be linear proportional to the segment size. My question is, has anybody noticed memory leaks in rc ? Malte. From rc-owner Sun May 3 15:56:51 1992 Received: from relay2.UU.NET ([137.39.1.7]) by archone.tamu.edu with SMTP id <45316>; Sun, 3 May 1992 15:52:14 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17146; Sun, 3 May 92 16:52:07 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 165145.20191; Sun, 3 May 1992 16:51:45 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa05261; Sun, 3 May 92 16:44:07 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: byron@archone.tamu.edu Subject: Re: rc and readline and SIGINT Cc: rc@archone.tamu.edu Date: Sun, 3 May 1992 15:39:22 -0500 Message-Id: <9205031639.aa06245@ceres.srg.af.mil> Here is my patch to handle readline as a slow system call so that SIGINT does the "right" thing. For this to work you MUST compile with SVSIGS undefined. I haven't had a lot of time to test this, but it is a direct copy of how "slow" system calls are currently handled by rc and it seems to work OK. I would be grateful if other folks who use readline would try this and see how it works for them. Many thanks to Chet and Byron for their help with this. Tom *** input.c~ Tue Mar 31 12:50:15 1992 --- input.c Sun May 3 16:07:47 1992 *************** *** 88,99 **** the buffer to look like a regular fdgchar buffer. */ static int fdgchar() { if (chars_out >= chars_in + 2) { /* has the buffer been exhausted? if so, replenish it */ while (1) { #if defined(READLINE) || defined(EDITLINE) if (interactive && istack->fd == 0) { ! rlinebuf = readline(prompt); if (rlinebuf == NULL) { chars_in = 0; } else { --- 88,119 ---- the buffer to look like a regular fdgchar buffer. */ + #ifdef READLINE + extern char *rc_readline(char *prompt) { + char *r; + interrupt_happened = FALSE; + if (!setjmp(slowbuf.j)) { + slow = TRUE; + if (!interrupt_happened) + r = readline(prompt); + else + r = NULL; + } else + r = NULL; + slow = FALSE; + if (r == NULL) + errno = EINTR; + SIGCHK; + return r; + } + #endif + static int fdgchar() { if (chars_out >= chars_in + 2) { /* has the buffer been exhausted? if so, replenish it */ while (1) { #if defined(READLINE) || defined(EDITLINE) if (interactive && istack->fd == 0) { ! rlinebuf = rc_readline(prompt); if (rlinebuf == NULL) { chars_in = 0; } else { From rc-owner Tue May 5 13:37:56 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by archone.tamu.edu with SMTP id <45322>; Tue, 5 May 1992 13:31:12 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA20750; Tue, 5 May 92 20:31:03 +0200 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA07073; Wed, 22 Apr 92 11:54:28 +0200 Date: Wed, 22 Apr 1992 04:54:28 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9204220954.AA07073@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: Re: trailing newlines In-Reply-To: Mail from 'The Post Office ' dated: Tue, 21 Apr 1992 18:00:21 -0500 I'm not sure if I get the point, but isn't this what you want: x = `` ($nl) { echo $x } # strips all newlines or fn deletenl { * = `` ($nl) { echo $* } while ( ! ~ $#* 0 1 ){ # echo all args but the last echo $^1 shift } echo -n `` ($nl) { echo $^1 } # echo last arg without nl } x = `` () { deletenl $x } To be honest, deletenl squeezes repeated nls into one. Malte. From rc-owner Wed May 6 17:19:03 1992 Received: by archone.tamu.edu id <45316>; Wed, 6 May 1992 17:02:13 -0500 From: Byron Rakitzis To: rc Subject: rc Hack of the Day Message-Id: <92May6.170213cdt.45316@archone.tamu.edu> Date: Wed, 6 May 1992 17:01:59 -0500 From: dylan@ibmpcug.co.uk (Matthew Farwell) Newsgroups: alt.hackers Subject: Re: Start posting hacks; give up on drivel. Date: 26 Apr 92 14:51:42 GMT Organization: The IBM PC User Group, UK. In article <1992Apr25.150903.6680@usage.csd.unsw.OZ.AU> peteru@hydra.maths.unsw.OZ.AU writes: >C'mon guys (are there any girls around?) why do we have to argue about the >ability to telnet to a machines News port (anyone can grep the port number >from /etc/services) and forge a message so that no-one can trace you. You don't even need to do the grep. Most telnets recognise the name (ie nntp) as well, so you can just telnet kate.ibmpcug.co.uk smtp. ObHack(well ish). Our machine has a motherboard problem (well we think its a motherboard problem anyway). Every two of three weeks, the machine decides it not going to read the root filesystem. This is unfortunate, since it precludes doing subtle things like running commands (you have to stat /, remember). Anyway, I got sick of having to wait for fsck's to happen every time the machine crashed, so I modified rc slightly, and added sync and haltsys as builtins. I'm therefore probably the only person in the world with haltsys as a builtin in his shell... -- "It's at times like this I wish I'd listened to what my mother used to say" "Why, what did she say?" "I don't know - I never listened." From rc-owner Tue May 12 14:54:10 1992 Received: from postman.osf.org ([130.105.1.152]) by archone.tamu.edu with SMTP id <45337>; Tue, 12 May 1992 14:38:16 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA14480; Tue, 12 May 92 13:25:03 -0400 Received: by earth.osf.org (5.64/4.7) id AA03499; Tue, 12 May 92 13:25:02 -0400 Date: Tue, 12 May 1992 12:25:02 -0500 From: rsalz@osf.org Message-Id: <9205121725.AA03499@earth.osf.org> To: rc@archone.tamu.edu Subject: Useful function It looks like line noise, but it turns things like /home/rsalz/foo/bar into ~/foo/bar Useful for when you put your current directory up in your icon title. By duplicating the $home section you can make things like /project/dce/build/dce1.0.1/src/rpc become $MYBT/src/rpc ## If a pathname starts with $home, turn $home into ~. Uses all built-ins. fn tildepath { p1=() i=() { p1=$1 switch ($p1) { case $home $home/* # Split arg into components *=`` (/) { echo -n $p1 } # Shift down by number of components in $home for (i in `` (/) { echo -n $home } ) shift # Glue back together p1='~' for (i) p1=$p1 ^ '/' ^ $i echo $p1 case * echo $p1 } return 0 } } From rc-owner Thu May 14 17:21:48 1992 Received: from relay1.UU.NET ([137.39.1.5]) by archone.tamu.edu with SMTP id <45323>; Thu, 14 May 1992 17:13:41 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17627; Thu, 14 May 92 18:13:21 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 181235.2100; Thu, 14 May 1992 18:12:35 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa06046; Thu, 14 May 92 17:53:53 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@archone.tamu.edu Subject: Big trouble in little shell Date: Thu, 14 May 1992 16:54:33 -0500 Message-Id: <9205141754.aa23985@ceres.srg.af.mil> We desperately need something like "env - ..." or a mechanism to prevent variables from being exported built into rc. (Although a function could be written to unset every variable and function listed by "whatis" it would be dog slow.) (Maybe I should make this an rc script challenge just to see if you folks are listening...) While this may not be in the spirit of Plan 9 in general or rc in particular, it is essential in the real world for dealing with brain dead unix utilities that have limited environment and argument space. In rc scripts I commonly find myself writing wrapper functions like: fn expr { files=() dirs=() { /bin/expr $* } } fn test { files=() dirs=() { /bin/sh -c 'test '^$^* } } just to avoid "/bin/expr: arg list too long" and "/bin/sh: arg list too long" errors due to too much stuff in the environment. Currently a "generic" wrapper function like: "fn expr { env - /bin/expr $* }" won't work because env also chokes on big environments! There are other very good reasons for wanting to limit what is in the environment passed to a child process, but this one seems like enough of a reason on it's own. Tom From rc-owner Thu May 14 19:55:25 1992 Received: from po5.andrew.cmu.edu ([128.2.10.105]) by archone.tamu.edu with SMTP id <45322>; Thu, 14 May 1992 19:52:15 -0500 Received: by po5.andrew.cmu.edu (5.54/3.15) id for rc@archone.tamu.edu; Thu, 14 May 92 20:52:08 EDT Received: via switchmail; Thu, 14 May 1992 20:52:06 -0400 (EDT) Received: from hebe.weh.andrew.cmu.edu via qmail ID ; Thu, 14 May 1992 20:51:49 -0400 (EDT) Received: from hebe.weh.andrew.cmu.edu via qmail ID ; Thu, 14 May 1992 20:51:34 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hebe.weh.andrew.cmu.edu.pmax.ul4 via MS.5.6.hebe.weh.andrew.cmu.edu.pmax_ul4; Thu, 14 May 1992 20:51:34 -0400 (EDT) Message-Id: Date: Thu, 14 May 1992 19:51:34 -0500 From: "Josh N. Pritikin" To: rc@archone.tamu.edu Subject: Re: Useful function In-Reply-To: <9205121725.AA03499@earth.osf.org> References: <9205121725.AA03499@earth.osf.org> Beak: Is not. > It looks like line noise, but it turns things like > /home/rsalz/foo/bar > into > ~/foo/bar > ... Amazing, but can you write this with only builtins? fn setprompt { prompt = ($shost ^ : ^ `{echo $cwd | sed -e 's|'^$h^'|$h|' -e 's|/afs/andrew.cmu.edu/usr[^/]*|$u|' -e 's|.*[^/]\(/[^/]*/[^/]*\)|\1|'} ^ '>' ' ') } ( Josh Pritikin joshp+@cmu.edu ( It might be hot in Pittsburgh, but at least it's humid. From rc-owner Fri May 15 10:34:25 1992 Received: from postman.osf.org ([130.105.1.152]) by archone.tamu.edu with SMTP id <45324>; Fri, 15 May 1992 10:30:35 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA22284; Fri, 15 May 92 11:29:07 -0400 Received: by earth.osf.org (5.64/4.7) id AA18706; Fri, 15 May 92 11:29:06 -0400 Date: Fri, 15 May 1992 10:29:06 -0500 From: rsalz@osf.org Message-Id: <9205151529.AA18706@earth.osf.org> To: culliton@srg.af.mil, rc@archone.tamu.edu Subject: Re: Big trouble in little shell Something like this? Not tested, but should work or be easily debuggable. (Where have you heard that before? :-) This doesn't distinguish between variables and functions. If you need to do that, have another variable set of functions similar to these: ## The names of variables and funtions we don't want to export. unexported=() ## Add $1 $2 ... to the unexport list: unexport home mycd fn unexport { unexported=($unexported $*) } ## Remove $1 $2 ... from the unexported list: export home mycd fn export { new=() i=() u=() { for (i) { new=() for (u in $unexported) ! ~ $i $u && new=($new $u) uexported=($new) } } } Now, the key function. If you separate vars and functions, you'll have to have two loops, one for each unexportation. :-) ## Wrapper to remove unexported things before calling an external program. ## If first word is wrap, exec rest of line, otherwise exec the entire line. ## Add your own names for some functions here. fn wrap expr test { i=() { @ { for (i in $unexported) { eval $i ^ '=()' eval 'fn ' ^ $i } i=() ~ $0 wrap && shift eval 'exec builtin $*' } } } Addendum: I used to want export/unexport built into the shell, too. I even sent a diff by Byron, as I remember. I'm glad to see that (a) the shell didn't become cluttered by my change; and (b) I've learned enough to figure out how to do the above. /r$ From rc-owner Sat May 16 22:52:36 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45325>; Sat, 16 May 1992 22:49:52 -0500 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2690>; Sat, 16 May 1992 23:49:36 -0400 To: rc@archone.tamu.edu Subject: Re: pgrp? In-reply-to: schwartz's message of Sun, 26 Apr 92 14:10:40 -0400. <92Apr26.141043edt.2538@groucho.cs.psu.edu> Date: Sat, 16 May 1992 22:49:30 -0500 From: Chris Siebenmann Message-Id: <92May16.234936edt.2690@hawkwind.utcs.toronto.edu> | Should rc take care that the tty is in the proper process group | after a child exits? It should at least have a primitive, like newpgrp, that sticks the tty into the right group; it might be worthwhile to just smash away in the code if everyone is going to stick it into their prompt function. - cks From rc-owner Wed May 20 15:34:28 1992 Received: by archone.tamu.edu id <45322>; Wed, 20 May 1992 15:22:48 -0500 From: Byron Rakitzis To: rc Subject: SCO login Message-Id: <92May20.152248cdt.45322@archone.tamu.edu> Date: Wed, 20 May 1992 15:22:37 -0500 Anyone care to lend me a SCO login so I can try to track down a mysterious problem related to backgrounding jobs on that system? Thanks, Byron. From rc-owner Thu May 21 01:11:42 1992 Received: by archone.tamu.edu id <45322>; Thu, 21 May 1992 01:08:39 -0500 From: Byron Rakitzis To: rc Subject: 1.4 Message-Id: <92May21.010839cdt.45322@archone.tamu.edu> Date: Thu, 21 May 1992 01:08:39 -0500 Hi, this is a tentative announcement for rc-1.4. I've put up a file called "rc-1.4-no-editline.tar.Z" up for ftp on archone. It contains what it says: something I consider to be rc-1.4 without the editline package. I haven't yet resolved the status of editline, but I still want to push this code out of the door as fast as possible, because I am leaving this job within a week or so. I do not anticipate any changes to the code between now and the announcement of rc-1.4 on the net, except possibly some tweaks to the editline interface. (which is why I want to clearly mark this archive as being different) I have not made any changes to editline as of 1.4beta, but those of you who use it may want to ask Simmy what is going on. A note to SCO users: the macro NOJOB may need to be defined to prevent rc from dumping core on a background job (that's the latest word from Tom Culliton). I have *no* *idea* what could possibly be causing this core dump, since the difference between NOJOB and the default backgrounding procedure is a few calls to ioctl(), setpgrp() and signal(). Please let me know about any trouble you have with the code in the next week, and I'll try to fix stuff asap. I don't know about my mail access after next week, so you'll be on your own by the looks of it. Summary of changes from 1.4beta to 1.4 follow. Byron. ------ getopt was renamed to rc_getopt to avoid libc collisions. $cdpath with a / in it caused a cd to sometimes have two //'s in it. This is reserved by POSIX, so I changed it to skip one of the /'s. signal handling now emulates sh in the way I described in a previous message: the race condition present in older rc's whereby some SIGINTs got lost is now gone; any SIGINT received during a wait() is acted upon at the end of the wait(), unless of course SIGINT is being deliberately ignored. getopt was renamed to avoid naming conflicts with libc. Also a sound move since rc_getopt is no longer quite libc-getopt compatible; I had to add in a mechanism for resetting getopt. signal handler code in fn.c was cleaned up; there were several bugs in rc-1.4beta, notably the shell sometimes spawned background jobs with SIGTERM ignored. I took the opportunity to make things a little cleaner here. a quasi-memory leak in the code for while() was fixed: a long-running while that had rc commands allocating memory in it could cause the shell to grow without bounds. I fixed this by placing the while loop (*and* test!) inside a new allocation arena each time through the loop. A new configuration parameter, NOJOB, was added to allow you to force v7-style backgrounding (no setpgrp, ignore SIGINT and SIGTERM). From rc-owner Mon May 25 02:05:31 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <45322>; Mon, 25 May 1992 01:31:11 -0500 Received: by doolittle.vetsci.su.oz.au id <49165>; Mon, 25 May 1992 16:30:27 +1000 From: John (_You_ hide, they seek.) Mackin Date: Mon, 25 May 1992 01:23:19 -0500 To: Byron Rakitzis cc: The rc Mailing List Subject: Open Letter Message-ID: <199205251623.10041.rc.bajut@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Byron, This open letter to you is prompted by your statement that you're leaving your job and may not have Internet access after that. I just want to express my thanks for the wonderful job you have done on rc, and for all the effort you have put into making it the excellent program that it is today. I do not doubt that, in many ways, your implementation will prove superior to the original; not least because of the opportunities for cooperative development that are a direct consequence of your choice to release your code and make it freely distributable. Great work man, just top-notch. Best wishes for the future. OK, John. From rc-owner Mon May 25 17:26:29 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45323>; Mon, 25 May 1992 17:16:35 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Mon, 25 May 1992 18:15:59 -0400 To: Byron Rakitzis Cc: The rc Mailing List Subject: Re: Open Letter In-reply-to: Your message of "Mon, 25 May 92 02:23:19 EDT." <199205251623.10041.rc.bajut@vetsci.su.oz.au> Date: Mon, 25 May 1992 17:15:39 -0500 From: schwartz@groucho.cs.psu.edu Message-Id: <92May25.181559edt.2538@groucho.cs.psu.edu> John writes: | Great work man, just top-notch. Best wishes for the future. I agree completely. Thanks Byron! From rc-owner Mon May 25 17:33:54 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45325>; Mon, 25 May 1992 17:26:40 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Mon, 25 May 1992 18:20:00 -0400 To: rc@archone.tamu.edu Subject: one last bug Date: Mon, 25 May 1992 17:19:42 -0500 From: schwartz@groucho.cs.psu.edu Message-Id: <92May25.182000edt.2538@groucho.cs.psu.edu> As advertised, fifos are still sticky. echo <{echo} hangs, for instance. (SunOS 4.1.1, gcc2.0). Anyone have a /dev/fd driver for SunOS? What will become of the mailing list in the future? Should we migrate to comp.unix.shell? From rc-owner Mon May 25 17:47:49 1992 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45324>; Mon, 25 May 1992 17:39:36 -0500 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2717>; Mon, 25 May 1992 18:39:13 -0400 To: rc@archone.tamu.edu Subject: Re: one last bug In-reply-to: schwartz's message of Mon, 25 May 92 18:19:42 -0400. <92May25.182000edt.2538@groucho.cs.psu.edu> Date: Mon, 25 May 1992 17:39:00 -0500 From: Chris Siebenmann Message-Id: <92May25.183913edt.2717@hawkwind.utcs.toronto.edu> Fifos are being worked on and I've brought the mailing list up on hawkwind.utcs.toronto.edu. Two for two. :) - cks From rc-owner Mon May 25 17:56:27 1992 Received: from lisa.cs.widener.edu ([147.31.254.23]) by archone.tamu.edu with SMTP id <45327>; Mon, 25 May 1992 17:47:59 -0500 Received: by lisa.cs.widener.edu id AA21572 (5.65c/Widener-4.1 for rc@archone.tamu.edu); Mon, 25 May 1992 18:47:45 -0400 Date: Mon, 25 May 1992 17:47:45 -0500 From: Brendan Kehoe Message-Id: <199205252247.AA21572@lisa.cs.widener.edu> To: rc@archone.tamu.edu, schwartz@groucho.cs.psu.edu Subject: Re: one last bug If a home will be needed, I'd be happy to set the list up to originate from here, if necessary. From rc-owner Tue May 26 04:47:09 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by archone.tamu.edu with SMTP id <45328>; Tue, 26 May 1992 04:35:15 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA15818; Tue, 26 May 92 11:34:55 +0200 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA02390; Tue, 26 May 92 11:34:53 +0200 Date: Tue, 26 May 1992 04:34:53 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9205260934.AA02390@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: Re: one last bug There is more than one bug left; there is still a memory leak in rcs function handling. I'm still on the hunt. You might want to try this rc -p ; fn prompt {} ; to see that rc still grows larger and larger. Malte. From rc-owner Tue May 26 16:14:47 1992 Received: from stolaf.edu ([130.71.128.8]) by archone.tamu.edu with SMTP id <45322>; Tue, 26 May 1992 16:06:59 -0500 Received: from mari.acc.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA15020; Tue, 26 May 92 16:06:11 CDT Date: Tue, 26 May 1992 16:06:11 -0500 From: quanstro@stolaf.edu (Erik Quanstrom) Message-Id: <9205262106.AA15020@stolaf.edu> Received: by mari.acc.stolaf.edu (4.1/SMI-4.1) id AA03352; Tue, 26 May 92 16:06:04 CDT To: rc@archone.tamu.edu Subject: goosh --- an attempt to generalized rc I've been working on a new shell for the past several months which looks and behaves something like rc but has a few new and hopefully useful generalizations and simlifications. Goosh is fairly stable and available for anonomous ftp at ftp.stolaf.edu. Following is the README from the dist. major differences between goosh and most other shells. 0) heredocs are not supported because they are unnecesary. Here is a version of shar for goosh #!/bin/goosh if (~ $#* 0) { echo 'usage: shar file . . .' exit 1 } echo '#!/bin/goosh # This is a goosh archive. Save it in a file and remove anything before # the line `#!/bin/goosh'' and then unpack it bu entering "goosh ". # # this archive contains: # ' for (i in $*) echo '# ' $i echo '#' for (i in $*) { if (test -d $i) { echo 'echo c -' $i echo 'mkdir $1 >/dev/null >[2=1]' } else { echo 'echo x -' $i echo -n echo '''' sed 's/''/''''/' $i echo '''' '>' $i } } 1) no difference between functions a variables. That is one can make the assignment fu = bar just as well as fu = { builtin ls -AF $*; } 2) local assignment: To solve the local-variable problem, I have introduced a second assignment operator, <-. In goosh, = binds until the end of the (smallest) enclosing { } pair while <- changes the binding of a variable where it was defined. If a variable rebound with <- does not exits it is created in the top-level environment. The problem with rc's local assigment is that it requires variable declaration, which does not belong in a shell. Consider this code fragment. fn spell { flag=-2 dict=$dictionary word=() { ... } } This code is a little obtuse. In goosh there is no problem because = gives local binding. Thus the same function would be written in goosh as spell = { ... } 3) deep lists: goosh lists's are deep, meaning that a list man contain a list. Thus facillitating easy manipulation of recursive structures, most notablly directory trees.