It's good to see some discussion on the list again. You may have noticed that recent releases of rc have changed very little; this is because I am aiming to produce a very solid rc-1.7. After that, I want to start working towards rc-2. (Or shall we call it ActiveShell 2000? :-) I have a number of ideas for changes, which are listed below. The first section comments on the items listed in the BUGS section of the man page. The second section lists other items that I have a reasonably clear idea of how to tackle. The third section is more contentious or nebulous ideas. All comments are welcome. Tim. Documented bugs 1. The ^A bug. This will be fixed. 2. Compile-time limit on `;' separated commands in a line. I think it is possible to fix this, although it may not be worth the effort. 3. Problems with FIFOs. Has anybody ever actually seen these problems? If there's a repeatable test case, I can probably fix it. 4. `shift' only works on `$*'. This could be fixed, but it's not hard to write a function that can shift any variable (except one). Suggested fix is to the documentation: include the `anyshift' function, and remove this "bug". 5. Builtin `echo'. Well, it's not going away :-). There's always the compile-time option to omit it... 6. Avoid exporting a variable: see below. 7. `$^var' to join with an arbitrary separating character. Again, this is easy to fake with a function when needed. 8 & 9. Strange handling of parentheses. I think this can be fixed with some tweaks to the grammar, and probably is worth it. 10. `$PATH' versus `$path'. I think rc should prefer `$path' if both are set. Likewise for `$cdpath' and `$home'. 11. `.' should search `$path'. This will be fixed. 12. Extra parentheses around `~' and `!' are syntax errors (you'll have to get rc-1.6b2 to see what this is about). I suspect that these "surprising" special cases can be fixed with minor tweaks to the grammar. (Suggestion due to Bengt Kleberg.) Other likely changes 13. Add the `flag' builtin as described in this document. (I've considered a few "improved" versions of this, but I think the original specification is pretty much spot on.) http://www.star.le.ac.uk/~tjg/rc/misc/td.html 14. Add a command line flag that means "don't export any variables". (Any suggestions for a mnemonic letter?) This is fairly useless on the command line, but in conjunction with `flag' solves bug 6 neatly. (Actually, the flag will probably mean "don't export any variables, except those set in temporary assignments", which is rather more useful.) 15. Fake bidirectional pipes on systems where `pipe()' produces a unidirectional pipe, but `socketpair()' exists. (Suggestion due to Charles Forsyth, via John Murdie.) 16. Make `*' match files beginning with `.' (except `.' and `..', of course). This is something of a religious question, but my feeling is that special treatment of "dot files" is a mistake. (Suggestion ditto.) 17. Improved error reporting, as discussed on the list recently. Also, I intend that rc should prefix its errors with `rc: '; the long standing Unix tradition that shells are special in this regard is not very useful, I think. 18. Support BSD editline, and clean up the readline, editline, vrl, etc. interface if possible. (Suggestion due to Raymond Venneker.) 19. Discard autoconf and automake. I wrote a long message to the <9fans> list about some of my objections to autoconf. I have a replacement system in the wings. Other possible changes. 20. ~ expansion. 21. Add a command line flag that turns off free carets. 22. Add a `sigeof' function, which is invoked when rc sees EOF on standard input when it's a terminal device. If sigeof returns 1, rc attempts to continue reading from standard input. fn sigeof { echo 'Type `exit'' to leave the shell' >[1=2]; return 1 } (Suggestion due to Mark K Gardner.) 23. Dynamically load readline only when rc is about to read from a terminal device. This would mean that a single rc binary would be lean and fast for scripts, but still do readline for interactive use. However, I suspect that the effort involved in making this happen portably would be considerable. 24. Make `$ifs' behaviour "smarter". The problem is that sometimes you want repeated separators to indicate a null value, sometimes not. ; # ifs has its default value ; x = `{ echo 'this is a test' } ; whatis x x=(this is a test) ; ifs=, ; x = `{ echo this,is,,a,test } ; whatis x x=(this is a 'test ') But in the second example, we'd really like to see this. x=(this is '' a test) One suggestion (due to Donn Cave) is to make rc use its existing rules when `$ifs' contains multiple characters, and to use "repeated separators imply null values" when `$ifs' contains only a single character. (There is a separate question of whether newlines should be trimmed in this case.) I see the problem, but I'm not keen on this solution. 25. Gert-Jan Vons complains that using `=' in a command's arguments is a syntax error. I find this frustrating, too, but I can't think of a cure that isn't worse than the disease. 26. Better testing. It bothers me that I have added 22 "Bug:" entries to the ChangeLog, but only 4 regression tests to trip.rc. To some extent, this is inevitable. It simply isn't possible for trip.rc---or any test infrastructure that can work wherever rc does---to create a file which the user is entitled to execute only because of a secondary group membership, or to construct a file which can be open()ed for reading, but not read(). But I think we should do better. A second problem with trip.rc is that it assumes certain Unixisms, so it doesn't work at all under CygWin, for instance. 27. Smaller, faster, cheaper. I don't think rc has any major inefficiencies, but I will certainly throw some profiling tools at it, to see if there are improvements to be made. In this context, "cheaper" means smaller to download, or faster to build. I think the new Makefile maker mentioned in 19 will achieve both these goals. 28. That's all for now, folks!
re: shift, i disagree with the idea of an "anyshift" function, given that it's so easy to make an extended shift backwards-compatible. see the patch i either posted here or mailed to tim earlier this year. i seem to recall that my builtin was shorter or the same length as the current one. i think it's silly to hack around something that we can so easily and cleanly fix properly. re: dot files i agree that special treatment of dot files is mistake. re: improved error reporting this would be a great benefit. my own copy of rc is hacked to sort of do this, but it's not quite right and you're as well off doing it again from scratch (i know i would). rc should prefix its errors "rc: ". re: = in args this is a real pain, but i take your word for it that changing the interpretation of = past the first non-assignment in a line is hard. -e -- "As the Chinese say, 1001 words is worth more than a picture." -- John McCarthy
> You may have noticed that recent releases of rc have changed very > little; this is because I am aiming to produce a very solid rc-1.7. That would be great. > After that, I want to start working towards rc-2. (Or shall we call it > ActiveShell 2000? :-) Is there really a need for an rc-2? After all, what appeals to me most about the shell is its perfect minimalism -- adding any new features to rc could easily make it worse, not better. The bugs you listed as needing fixing seem reasonable, though (as you pointed out for things like the limit on ;-separated commands on a line or ``='' not used for assignment) the cure may sometimes be worse than the disease. I have some specific comments on your suggestions. > 1. The ^A bug. This will be fixed. How? With es, we use combinations of ^A and ^B, but it's at least as gross a hack as not allowing ^A. (If you do change this, unless you've got a very good reason, try to make it compatible with es.) > 8 & 9. Strange handling of parentheses. I think this can be fixed with > some tweaks to the grammar, and probably is worth it. > > 12. Extra parentheses around `~' and `!' are syntax errors (you'll > have to get rc-1.6b2 to see what this is about). I suspect that these > "surprising" special cases can be fixed with minor tweaks to the > grammar. (Suggestion due to Bengt Kleberg.) I don't understand the complaints here. These are not bugs, IMHO, just consequences of a simple grammar. Do not underestimate how complicated you will make the grammar by changing these. > 10. `$PATH' versus `$path'. I think rc should prefer `$path' if both > are set. Likewise for `$cdpath' and `$home'. I think there was a good reason for preferring $PATH: rc invokes a sh(1) script which sets $path and then invokes and rc script. Changing this behavior would be a mistake. > 11. `.' should search `$path'. This will be fixed. Why? Who uses ``.'' that frequently that it's an issues? I think the files you run with ``.'' are rarely the same programs you want to run with normal execution rules, so I'd prefer keeping it the way it is. > 13. Add the `flag' builtin as described in this document. (I've > considered a few "improved" versions of this, but I think the original > specification is pretty much spot on.) Why? Duff's rc used flag so that rcinit could be used to implement startup flag processing. It was not generally useful, just part of the bootstrap process -- do you want to change the boot process as well? > 14. Add a command line flag that means "don't export any variables". > (Any suggestions for a mnemonic letter?) This is fairly useless on > the command line, but in conjunction with `flag' solves bug 6 neatly. > (Actually, the flag will probably mean "don't export any variables, > except those set in temporary assignments", which is rather more > useful.) First, the semantics of this are hardly clear. What happens when you modify a variable which is already in the environment? Second, why bother? What need is there for this? > 15. Fake bidirectional pipes on systems where `pipe()' produces a > unidirectional pipe, but `socketpair()' exists. (Suggestion due to > Charles Forsyth, via John Murdie.) Why bother? How many times do you find programs that can communicate with the previous member of a pipeline by writing to their standard input? > 16. Make `*' match files beginning with `.' (except `.' and `..', of > course). This is something of a religious question, but my feeling is > that special treatment of "dot files" is a mistake. (Suggestion ditto.) You will alienate anyone who wants cultural compatibility with normal Unix shells. Compatibility with plan 9 is much less important, I think, than matching Unix users' expectations, especially those of us who've already been using Byron's rc since 1992. > 17. Improved error reporting, as discussed on the list recently. Also, > I intend that rc should prefix its errors with `rc: '; the long standing > Unix tradition that shells are special in this regard is not very > useful, I think. Adding the name of the script seems useful for errors reported from scripts. Adding a ``rc:'' prefix seems a mistake to me. > 19. Discard autoconf and automake. I wrote a long message to the > <9fans> list about some of my objections to autoconf. I have a > replacement system in the wings. I'm not on 9fans, so I missed your note, and I agree that the GNU tools are big and bloated, but this seems like a waste of time. > 20. ~ expansion. If you want to start a holy war, be my guest. I use ~-expansion, so I'm hardly one to complain about it. > 21. Add a command line flag that turns off free carets. This seems like a really, really bad idea to me. I used something derived from rc which didn't have free carets, and it was mighty painful. But percolating that change through the parsing system as a conditional option seems really unpleasant. The big problem with free carets is how they affect the implementation of the shell, and not its usage. You're proposing to complicate the implementation for the ``benefit'' of confusion for the end user, who now has two potential modes to run rc in. > 23. Dynamically load readline only when rc is about to read from a > terminal device. This would mean that a single rc binary would be > lean and fast for scripts, but still do readline for interactive use. > However, I suspect that the effort involved in making this happen > portably would be considerable. Ugh. All of these: > 4. `shift' only works on `$*'. This could be fixed, but it's not hard to > write a function that can shift any variable (except one). Suggested > fix is to the documentation: include the `anyshift' function, and remove > this "bug". > 6. Avoid exporting a variable: see below. > 7. `$^var' to join with an arbitrary separating character. Again, this > is easy to fake with a function when needed. > 24. Make `$ifs' behaviour "smarter". The problem is that sometimes you > want repeated separators to indicate a null value, sometimes not. [...] we ``fixed'' in es. Yes, they made the shell more general. Yes, they're used very occaisionally. But I'd be surprised to find them critical to rc. --p
A couple of comments, not exhaustive: > 12. Extra parentheses around `~' and `!' are syntax errors (you'll > have to get rc-1.6b2 to see what this is about). I suspect that these > "surprising" special cases can be fixed with minor tweaks to the > grammar. (Suggestion due to Bengt Kleberg.) They are not syntax errors -- ; while ((~ 1 1) && (~ 2 2)) {} ~ not found Parentheses introduce a word list -- a command list is introduced with {}. Thus: ; while ({! 1 1} && {! 2 2}) {} 1 not found 2 not found 1 not found 2 not found 1 not found 2 not found Maybe I don't understand the nature of the complaint. > 16. Make `*' match files beginning with `.' (except `.' and `..', of > course). This is something of a religious question, but my feeling is > that special treatment of "dot files" is a mistake. (Suggestion ditto.) I'm really unsure about the justification for this. This breaks compatability with so many versions of Unix that it really makes me wonder what the point is. Just because plan 9 doesn't have dotfiles doesn't necessarily mean we want to foist this on Unix users of rc. > 23. Dynamically load readline only when rc is about to read from a > terminal device. This would mean that a single rc binary would be > lean and fast for scripts, but still do readline for interactive use. > However, I suspect that the effort involved in making this happen > portably would be considerable. I don't even know what to say about this. The mind boggles. The idea that the readline library is so cumbersome that it needs to be dynamically loaded really weirds me out. Is it that huge now? Processors have improved by a couple orders of magnitude since I wrote rc! What if a talented programmer spent a month doing a readline replacement? Could he make it weigh in at 10% of the size of GNU readline? 5%? 1%? Sorry, it's late here and I'm babbling. Byron.
| 10. `$PATH' versus `$path'. I think rc should prefer `$path' if both | are set. Likewise for `$cdpath' and `$home'. I disagree for the already stated reasons. $PATH is standard on Unix; when rc starts, if $PATH and $path disagree, something has fiddled with $PATH and expects the fiddling to be respected. Similarly for $HOME and $home. | 11. `.' should search `$path'. This will be fixed. If Plan 9 rc doesn't, I don't think we should either. | 16. Make `*' match files beginning with `.' (except `.' and `..', of | course). This is something of a religious question, but my feeling is | that special treatment of "dot files" is a mistake. (Suggestion ditto.) This might be a good idea in a new shell, or for rc on a new system (without the cultural history of dotfiles). I think it is a really bad idea for an existing shell on an existing system, for all the obvious reasons. I would never run a version of rc that behaved this way here. | 17. Improved error reporting, as discussed on the list recently. Also, | I intend that rc should prefix its errors with `rc: '; the long standing | Unix tradition that shells are special in this regard is not very | useful, I think. My personal opinion is that rc should report errors in a shell script marked both with rc's name and with the script's name (so that it is obvious that it is a syntax error in the script, and not an error message being emitted by the script). I think rc should retain its current way of reporting the exit status of commands run directly from an interactive session. Whether rc should print 'rc: ' in front of syntax errors during interactive sessions seems like a religious issue. In the name of minimalism, I'd vote no. - cks
> 23. Dynamically load readline only when rc is about to read from a
> terminal device. This would mean that a single rc binary would be
> lean and fast for scripts, but still do readline for interactive use.
> However, I suspect that the effort involved in making this happen
> portably would be considerable.
What operating system doesn't demand-load the binaries anyway?
If you're not using the readline code, (the large majority of) it won't
be resident in memory.
And furthermore surely your OS is sharing text pages, so as long
as there is one rc binary running on a terminal, you've already got
it loaded and there's no penalty for running more or for running
scripts.
As Byron said, the mind boggles.
Russ
Tim Goodwin <tjg@star.le.ac.uk> writes: >4. `shift' only works on `$*'. This could be fixed, but it's not hard to >write a function that can shift any variable (except one). Suggested >fix is to the documentation: include the `anyshift' function, and remove >this "bug". >7. `$^var' to join with an arbitrary separating character. Again, this >is easy to fake with a function when needed. I prefer the latter option for both of these, given the simplicity of the workarounds and the lapse of time since the last argument about it. >10. `$PATH' versus `$path'. I think rc should prefer `$path' if both >are set. Likewise for `$cdpath' and `$home'. Ditto previous objections. Any sh/perl/etc. script that thinks it only needs to update PATH/HOME and happens to run an rc script would break. >11. `.' should search `$path'. This will be fixed. I'd be reluctant to possibly break scripts that assume that they can source a file from the current directory even if "." isn't in $path. >12. Extra parentheses around `~' and `!' are syntax errors (you'll >have to get rc-1.6b2 to see what this is about). I suspect that these >"surprising" special cases can be fixed with minor tweaks to the >grammar. (Suggestion due to Bengt Kleberg.) I agree with Byron; the current behaviour is the correct consequence of the syntax, not a bug. >13. Add the `flag' builtin as described in this document. (I've >considered a few "improved" versions of this, but I think the original >specification is pretty much spot on.) > > http://www.star.le.ac.uk/~tjg/rc/misc/td.html Since, with the possible exception of -x, there aren't any flags you'd want to turn on and off during the execution of a script, I don't know if there's any point to this. >14. Add a command line flag that means "don't export any variables". >(Any suggestions for a mnemonic letter?) This is fairly useless on >the command line, but in conjunction with `flag' solves bug 6 neatly. >(Actually, the flag will probably mean "don't export any variables, >except those set in temporary assignments", which is rather more >useful.) I once ran into a problem with a slide-show script which blew up because the shell variable holding the list of images to display took the environment past Linux's size limit for execve() and friends. I fixed the problem pretty simply, and haven't run into it again, but I can imagine situations where it isn't so easily avoided and the limitation is more frustrating. It's not entirely clear what it means to 'not export' a variable, though. Do we make it available only to the current invocation of the shell, and not to explicit subshells invoked via '@{ ... }', but still provide it to other subshells, such as in pipelines? I think it'd be worse to create a peculiar class of variables with a list of exceptions which make sense only if you know about the implementation. >15. Fake bidirectional pipes on systems where `pipe()' produces a >unidirectional pipe, but `socketpair()' exists. (Suggestion due to >Charles Forsyth, via John Murdie.) I'm not sure how useful this is, given that many utilities and the C/C++ library generally make sweeping assumptions that break badly when you try to make them interact through anything other than a (pseudo-)tty. The only application I can think of offhand is testing network software. I'd favour providing some helper program(s) for setting up bidirectionally connected programs and/or pipelines. >17. Improved error reporting, as discussed on the list recently. Also, >I intend that rc should prefix its errors with `rc: '; the long standing >Unix tradition that shells are special in this regard is not very >useful, I think. I tend to think prefixing errors with 'rc:' in interactive sessions is ugly, though it might have saved me some confusion in the past (I was trying to run "host" on a system where it wasn't installed, and began to think that DNS was down because I got "host not found" on every query...) >18. Support BSD editline, and clean up the readline, editline, vrl, etc. >interface if possible. (Suggestion due to Raymond Venneker.) As a 9term user, I mostly want to thrash out the old 'history' utility so that it compiles reliabily with optimization and doesn't sometimes skip lines with a lot of hyphens in them. >22. Add a `sigeof' function, which is invoked when rc sees EOF on >standard input when it's a terminal device. If sigeof returns 1, rc >attempts to continue reading from standard input. > > fn sigeof { echo 'Type `exit'' to leave the shell' >[1=2]; return 1 } > >(Suggestion due to Mark K Gardner.) I desired this briefly when I wanted to prevent accidentally logging out my console window, but I found that while () {. -i /dev/tty; echo NO NO NO NO} did the job for me. You can insert the continue-or-exit logic of your choice in place of the "NO" bit. >28. That's all for now, folks!
> > 23. Dynamically load readline only when rc is about to read from a > > terminal device. This would mean that a single rc binary would be > > lean and fast for scripts, but still do readline for interactive use. > > However, I suspect that the effort involved in making this happen > > portably would be considerable. > > I don't even know what to say about this. The mind boggles. The idea that > the readline library is so cumbersome that it needs to be dynamically > loaded really weirds me out. Is it that huge now? Processors have improved > by a couple orders of magnitude since I wrote rc! What if a talented > programmer spent a month doing a readline replacement? Could he make > it weigh in at 10% of the size of GNU readline? 5%? 1%? It's not *that* cumbersome. What about dynamic linking and shared libraries? Maybe I'm missing something here, but wouldn't simply linking rc against an already-installed readline library, if one exists, result in 90% of the benefits of rolling your own dynamic linking stuff without the pain? Bash has code in configure (and an option to select it) to figure out whether or not to link against a system version of libreadline rather than the version that comes in the bash distribution. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet) Chet Ramey, CWRU chet@po.CWRU.Edu http://cnswww.cns.cwru.edu/~chet/
When Tim mentioned "rc 2", I have to admit I was expecting something along the lines of "same functionality, 'better' internals". The amount and size of some of the changes being discussed is scary. ( different syntax, different variable handling, different execution semantics, and different input behaviour, and bigger, but otherwise business as usual ). And as Paul/Byron said, if you want some of this, go use es. The only one that makes sense to me is the error messages. I'd favour "rc:" on the command line, and "script-name:" for scripts. If you were going to always include "rc:", I'd want a space after it, so that it didn't confuse wily with "rc:script:nn". I'm not familiar with readline and its variants, having never explicitly gone out looking for it. Does it provide anything other than history recall and editing? If not, $history is enough to provide 99% of that functionality via an external program. steve
On Sun, Dec 19, 1999 at 06:06:54AM -0500, Steve Kilbane wrote: : I'm not familiar with readline and its variants, having never explicitly : gone out looking for it. Does it provide anything other than history : recall and editing? If not, $history is enough to provide 99% of that : functionality via an external program. I've always compiled rc with editline - it's much smaller than readline. I do use recall and editting frequently. The only hassle I've had is that interposing editline has occasionally tripped up the trip tests, and I've had to convince myself that rc was still okay... -- Christopher Vance
Tim Goodwin wrote, replying to me, replying to him: > > How? With es, we use combinations of ^A and ^B, > > I've considered a number of ideas, and had settled on using ^A and ^B > (independently: I didn't know that this was how es solved the problem). > I will look at es, and ensure that the rc fix is compatible. Great. > > but it's at least as > > gross a hack as not allowing ^A. > > I disagree here. I don't see anything gross about using a transparent > encoding. The ^A bug makes the world "not simple" for the user: you > have a perfectly good tool, except that it happens to fall apart for > certain cases. It's almost as bad as "sed: line too long". Do you want > people to use Perl? :-) I guess I've been bitten so rarely by the restriction that it doesn't bother me. Much more troublesome as a practical matter, IMNHO, is the restriction about not putting \0 in es strings, but that's much more problematic to ``fix.'' > Point 8 is that you can say this: > > fn foo { (x.y) = foo; echo $(x.y) } > > and `foo' works fine in the current shell, but not in descendant shells. > Again, I think this is a clear case of "not simple" for the user: either > the parent shell should reject the function definition, or it should > work in child shells. > > Now, it might turn out that fixing this turns out to be really hard, > in which case I won't bother. It's not that big a deal. But I have a > sneaking feeling that this is one of my favourite sort of bugs, where > the bug fix actually makes the code simpler. I think it's just a bug in footobar.c:Tconv(), where the current code is a little too pessimistic about when to insert parentheses. See the case which handles nCount, nFlat, and nVar. The test which sets lp and rp (using an audacious comma expression) should probably also look at the contents of the string to see if it's got ``interesting'' characters. > > I think there was a good reason for preferring $PATH: rc invokes a > > sh(1) script which sets $path and then invokes and rc script. Changing > > this behavior would be a mistake. > > A number of people have made the same point. I agree. However, given > this, I claim that $path and friends should not be exported by rc, nor > (ever) interpreted by descendant rc processes. Agreed. Es avoids exporting $path and $home for that reason. > > > 11. `.' should search `$path'. This will be fixed. > > Why? > Every other shell does, including (I'm told) the Plan 9 rc. Interesting. The docs for Plan 9 rc indicate that that's true, going back to the version in the printed 10th edition manuals. As do sh and its descendents, though not the csh family. According to Chet Ramey, Posix mandates path searching for ``.'' in csh. But Byron's rc never has, and I don't think it should. Byron put it better than I could in a note to this list from 1993: From: byron@netapp.com (Byron Rakitzis) To: davidf@golem.waterloo.on.ca Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: rc 1.5 Date: Fri, 16 Apr 1993 18:21:39 -0400 >Will 1.5 be brought into line with the Plan 9 man page? That's a good question. I'm hoping to freeze rc. I also don't feel the need to bring rc "into line" with anything else. So offhand I would say no. The flag command is present in plan9 rc for a very specific reason (/lib/rcmain). And I don't want dot to search my path. What if I do: ; cat >test <<EOF garbage EOF ; . test and "." is at the end of my path? Does this mean I run /bin/test as rc input? (THIS IS WHAT /bin/sh ACTUALLY DOES!!) No thank you. > > > 13. Add the `flag' builtin ... > > Why? > [...] The main reason is to make point 14 work, though. > > > > 14. Add a command line flag that means "don't export any variables". > > [...] > > Well, ever since I've been involved with rc the man page has listed > it as a bug, and there's been discussion on the list about it before. > Personally, I have no war stories, and you're right that it would add a > fair dose of complexity. > > Any other opinions? Does anyone have a real need for this? I would strongly suggest you leave this on the back burner (and perhaps remove the comment from the man page) until it becomes a pressing issue for real applications. > > > 15. Fake bidirectional pipes on systems where `pipe()' produces a > > > > Why bother? How many times do you find programs that can communicate > > with the previous member of a pipeline by writing to their standard > > input? > > It's utterly trivial to do, and there are apparently some Plan 9 > scripts that use it. Except that it adds at least one more #ifdef option, which is a much higher configuration and complexity increase than the utility of the feature merits. (I've come to believe that conditional compilation options are almost always wrong.) > > Adding a ``rc:'' prefix seems a mistake to me. > > Can you learn to live with it? (Me? I don't actually use rc anymore. As much as I use a shell, I use es, but I probably use complex shell commands once a day at most. But I continue to think of rc as one of the most nearly perfect programs I see, so my advice about it will always be radically conservative.) > In my job, I reach for strace, truss, or ktrace *every single day*. > At least 50% of the time it's to find out information about an error > situation which the application knew, but decided not to bother > reporting---and yes, sometimes, it's as fundamental as not even > knowing which application encountered an error. > > Stealing Smarasderagd's example, I know which of these I'd rather see. > > ; host microsoft.com > host not found > > ; host microsoft.com > rc: `host' not found > > Maybe you think those 6 extra characters are ugly. But they also make > it blindingly obvious what went wrong. I guess I work on enough different problems from you that this hasn't hit me. The quotes do help in the error message, I think, and are vastly preferable to the ``:'' sh and es use. The rc prefix doesn't add anything, but that's just my opinion. (I guess I don't want the shell to be drawing attention to itself.) Much more useful, I think, as an addition to error messages would be printing the program which actually died with a signal in a pipeline. For example, in: ; ls | sleep 1000 | wc 0 0 0 illegal instruction ; it could have been helpful to know that it was sleep that got killed. --p
Chet Ramey wrote, quoting me
> > Interesting. The docs for Plan 9 rc indicate that that's true, going
> > back to the version in the printed 10th edition manuals. As do sh and
> > its descendents, though not the csh family. According to Chet Ramey,
> > Posix mandates path searching for ``.'' in csh.
>
> I assume you mean `sh' here. POSIX.2, section 3.14.4.
Yes. Sorry for any confusion.
--p
Decklin Foster wrote: > > 5. Builtin `echo'. Well, it's not going away :-). There's always the > > compile-time option to omit it... > > We could always make echo an optionally-compile-inable builtin /a la/ > the stuff in addon.c, and make the people who want it figure out how > to have it be linked in... ;-) Not that *hard*, just annoying. No. Adding compile-time options is always worse. > > 10. `$PATH' versus `$path'. I think rc should prefer `$path' if both > > are set. Likewise for `$cdpath' and `$home'. > > Ooops. I thought, from reading the manpage, that rc updated $PATH if > something set $path and vice versa? I guess this must not be the case. It does the right thing. Play with it for a second to see: ; path = a b b not found ; path = (a b) ; echo $PATH a:b ; PATH=x:y ; echo $path x y ; > > 17. Improved error reporting, as discussed on the list recently. Also, > > I intend that rc should prefix its errors with `rc: '; the long standing > > Unix tradition that shells are special in this regard is not very > > useful, I think. > > Great. However, I went to go try to add this and discovered print.c. Adding it to print.c would be problematic, I think, because there's no distinguished function for printing errors. (I believe es uses eprint for that purpose.) And the important part, source file name and line number, requires understanding the somewhat more subtle stuff going on in input.c. > I must admit that i'm entirely lost in it. It *seems* to be a copy of > fprintf. Are we actually trying to be portable to systems without a > printf? :-) That code is my fault, if I remember properly. Byron and I were taken with the notion of the Plan 9 print() and fmtinstall(), and used that model pervasively. In particular, function exporting depends on the %T conversion rules -- see footobar.c:Tconv(). Other difference with the stdio printf family (aside from letting you install your own formatters), include that it works directly with file descriptors and is unbuffered. As to excesses in the NIH department, I'm pretty sure rc used to ship with its own malloc(), too. (Sun's malloc was very slow at one point.) > But seriously, there are some entry points which deal with this Format > structure that i'm not sure of the significance of... I suspect you're looking at mprint() which returns a string containing the formated output, allocated with malloc(), and nprint(), which does the same with nalloc() allocated memory. > > 18. Support BSD editline, and clean up the readline, editline, vrl, etc. > > interface if possible. (Suggestion due to Raymond Venneker.) > > also a more (intellegent, bloated, take your pick... ;-)) readline > interface. with bash readline can look inside variables and complete > against $PATH if it's the first word, and so on... If I can figure out > how to help with #17 and it gets fixed then I'll take a look at this. > Don't worry, i'll ask if I have to add anything *really* fattening. I thought making getenv do the right thing was most of the battle here. > > 20. ~ expansion. > > I am, of course, biased for this, if only because I haven't actually > used ~ for matching in a script yet... Here's my question. Is there > really anything about '~' (the builtin) that can't be done with an > external program? Why does it get a special glyph indtead of a name > like 'match'? I never use '[' for 'test' when i'm using rc... It got a special character because Tom Duff said it did. But it can't be confined to an external program because it uses the globbing rules, so it needs to distinguish between, say, unquoted * and quoted '*'. > Obviously, you can argue that there's nothing at all essential about > using ~ to denote $home, but you have to make a tradeoff somwhere. It can easily do both. It does in es, and in several rc variants people have hacked up. --p
Greetings, After a (too long) delay I offer my comments to the rc-2.0 wish-list. Points where I have no comment are just left out. > 2. Compile-time limit on `;' separated commands in a line. Good idea, it would be nice to remove built-in limits, and just leave te hard ones (RAM/swap space). > 4. `shift' only works on `$*'. Yes, please add this to the documentation. I needed it a few days ago (last millenium :-), and could not invent it. > 8 & 9, 12. Strange handling of parentheses. Since my misunderstanding of while () {} probably started this thread I would like to add that I now understand that syntax errors from while (()) {} is a feature and not a bug. However, it is confusing and should merit a comment in the documentation of while/if/for > 10. `$PATH' versus `$path'. Please let $path inherit from $PATH, and also assigments to $path be reflected back to $PATH. I would much prefer to think of them as always having the same value. > 11. `.' should search `$path'. Actually, I do not think so. I think it should not. > 16. Make `*' match files beginning with `.' Please do not. > 17. Improved error reporting Yes. A error report like script-name:line-number 'error' would be very useful. > 19. Discard autoconf and automake. Yes please. If this is 'a waste of time' for skilled programmers, consider using my time (it can be wasted upon such activities :-) \x1f> 20. ~ expansion. If absolutly neccessary, please make it a compile time option. > 21. Add a command line flag that turns off free carets. If I remember correctly this is a compile time option already. That is surely enough. > 23. Dynamically load readline only when rc Please do not. How about suggesting 2 rc shells in the documentation instead? One for scripts, and one for interactive use. The latter with readline, the former without. > 25. Gert-Jan Vons complains that using `=' in a command's arguments It is ok as it is. I have gotten used to it. > 26. Better testing. Very good idea. Any thing in particular you want a test for? > 27. Smaller, faster, cheaper. Make this #1. And finally, for my personal enjoyment: How about re-introducing if not {} as an alternative to } else { } I have 1 need for this, and I really think it would be nice to have both possiblities. Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.''
First of all, Happy New Year to you all! Thanks to everybody who replied to my message about possible future directions for rc: it's been great to see the discussion. I've taken Paul Haahr's message as a starting point to say more on some points... To try to stop the discussion spiralling off into ever longer messages, I'll initiate separate threads for some of the more controversial items. > Is there really a need for an rc-2? After all, what appeals to me most > about the shell is its perfect minimalism -- adding any new features to > rc could easily make it worse, not better. I agree. I certainly don't intend to tarnish rc's minimalism. I should have stressed this more in my first message: the aim is to round off (a very few) rough corners, without adding lots of new features or extra code. To look at it another way, I think rc's most important aspect is that it is *simple*. (One reason I use rc is that I know that I know its quoting rules. I *think* that I know the sh quoting rules, but that's not quite the same thing...) Simplicity exists at a number of levels, and in most cases there is little conflict between "simple for the implementor", "simple for the installer", and "simple for the user". There are a few places, though, where I think I can make rc even simpler. Finally, I should have made it much clearer in my original message that some of the wackier ideas were just "brain storming", and may never come anywhere near being implemented. > > 1. The ^A bug. This will be fixed. > > How? With es, we use combinations of ^A and ^B, I've considered a number of ideas, and had settled on using ^A and ^B (independently: I didn't know that this was how es solved the problem). I will look at es, and ensure that the rc fix is compatible. > but it's at least as > gross a hack as not allowing ^A. I disagree here. I don't see anything gross about using a transparent encoding. The ^A bug makes the world "not simple" for the user: you have a perfectly good tool, except that it happens to fall apart for certain cases. It's almost as bad as "sed: line too long". Do you want people to use Perl? :-) > > 8 & 9. Strange handling of parentheses. I think this can be fixed with > > some tweaks to the grammar, and probably is worth it. > > > > 12. Extra parentheses around `~' and `!' are syntax errors (you'll > > I don't understand the complaints here. My point 12 was bogus, I was rushing. Ignore it. Point 8 is that you can say this: fn foo { (x.y) = foo; echo $(x.y) } and `foo' works fine in the current shell, but not in descendant shells. Again, I think this is a clear case of "not simple" for the user: either the parent shell should reject the function definition, or it should work in child shells. Now, it might turn out that fixing this turns out to be really hard, in which case I won't bother. It's not that big a deal. But I have a sneaking feeling that this is one of my favourite sort of bugs, where the bug fix actually makes the code simpler. > I think there was a good reason for preferring $PATH: rc invokes a > sh(1) script which sets $path and then invokes and rc script. Changing > this behavior would be a mistake. A number of people have made the same point. I agree. However, given this, I claim that $path and friends should not be exported by rc, nor (ever) interpreted by descendant rc processes. > > 11. `.' should search `$path'. This will be fixed. > > Why? Every other shell does, including (I'm told) the Plan 9 rc. > > 13. Add the `flag' builtin ... > > Why? I can think of occasions where `flag x +' or `flag e +' would be marginally useful. The main reason is to make point 14 work, though. > > 14. Add a command line flag that means "don't export any variables". > > First, the semantics of this are hardly clear. What happens when you > modify a variable which is already in the environment? > > Second, why bother? What need is there for this? Well, ever since I've been involved with rc the man page has listed it as a bug, and there's been discussion on the list about it before. Personally, I have no war stories, and you're right that it would add a fair dose of complexity. Any other opinions? Does anyone have a real need for this? > > 15. Fake bidirectional pipes on systems where `pipe()' produces a > > Why bother? How many times do you find programs that can communicate > with the previous member of a pipeline by writing to their standard > input? It's utterly trivial to do, and there are apparently some Plan 9 scripts that use it. > > 16. Make `*' match files beginning with `.' (except `.' and `..', of A number of people have expressed strong opinions on this one. In both directions, of course :-). I think the status quo prevails. > > 17. Improved error reporting, > > Adding the name of the script seems useful for errors reported from > scripts. There seems to be general agreement on this point. > Adding a ``rc:'' prefix seems a mistake to me. Can you learn to live with it? In my job, I reach for strace, truss, or ktrace *every single day*. At least 50% of the time it's to find out information about an error situation which the application knew, but decided not to bother reporting---and yes, sometimes, it's as fundamental as not even knowing which application encountered an error. Stealing Smarasderagd's example, I know which of these I'd rather see. ; host microsoft.com host not found ; host microsoft.com rc: `host' not found Maybe you think those 6 extra characters are ugly. But they also make it blindingly obvious what went wrong. Alternatively, we could discard the notion that error messages are supposed to help people, and just report every error with "?", or maybe "A device attached to the system is not functioning". :-) > > 19. Discard autoconf and automake. This deserves a separate thread. > > 20. ~ expansion. > > If you want to start a holy war, be my guest. :-) Actually, I'm not a huge fan of ~ expansion, probably because I've never never used a shell that supported it. People seem to like it, but I think it's far too unwieldy to add to rc. It's at least possible that I will some day write the utility getpwnam(1). With this, you could define ; fn h { getpwnam $1 | cut -d: -f6 } and then say ; ls `{h fred} But I don't suppose those arguing for ~ expansion in the shell think much of this idea... > If you want to start a holy war, be my guest. I use ~-expansion, so I'm > hardly one to complain about it. > > 21. Add a command line flag that turns off free carets. > > This seems like a really, really bad idea to me. You're right. It was a lousy idea. > > 23. Dynamically load readline only when rc is about to read from a > > terminal device. > > Ugh. Yes, ugh, but... (Separate thread for this one, too.) Tim.
[boy, I'm late replying to this. *don't* ask where i've been...] Tim Goodwin writes: > 5. Builtin `echo'. Well, it's not going away :-). There's always the > compile-time option to omit it... We could always make echo an optionally-compile-inable builtin /a la/ the stuff in addon.c, and make the people who want it figure out how to have it be linked in... ;-) Not that *hard*, just annoying. > 6. Avoid exporting a variable: see below. Why do we need this? My apologies if this has already been gone over. I always thought it was some bizzare sh-ism that I was destined never to understand... > 10. `$PATH' versus `$path'. I think rc should prefer `$path' if both > are set. Likewise for `$cdpath' and `$home'. Ooops. I thought, from reading the manpage, that rc updated $PATH if something set $path and vice versa? I guess this must not be the case. > 11. `.' should search `$path'. This will be fixed. Well, we've had some debate here (and i'm definetly on the `against' side.) My request is this: bash allows 'source' as a synonym for '.'. I can make a 'source' function for interactive use, but interactively I'd just type '.' anyway (it's shorter after all). I just prefer 'source' in shell scripts because it's vastly more readable IMHO. especially when sourcing a dotfile. And scripts can't pull this hypothetical function out of my $home/.rcrc, unless i'm mistaken. > 17. Improved error reporting, as discussed on the list recently. Also, > I intend that rc should prefix its errors with `rc: '; the long standing > Unix tradition that shells are special in this regard is not very > useful, I think. Great. However, I went to go try to add this and discovered print.c. I must admit that i'm entirely lost in it. It *seems* to be a copy of fprintf. Are we actually trying to be portable to systems without a printf? :-) But seriously, there are some entry points which deal with this Format structure that i'm not sure of the significance of... So can anyone lend a hand? I'd really like to grok this code. If you only reply to one issue in this mail, make it this one. > 18. Support BSD editline, and clean up the readline, editline, vrl, etc. > interface if possible. (Suggestion due to Raymond Venneker.) also a more (intellegent, bloated, take your pick... ;-)) readline interface. with bash readline can look inside variables and complete against $PATH if it's the first word, and so on... If I can figure out how to help with #17 and it gets fixed then I'll take a look at this. Don't worry, i'll ask if I have to add anything *really* fattening. > 19. Discard autoconf and automake. I wrote a long message to the > <9fans> list about some of my objections to autoconf. I have a > replacement system in the wings. That'd be nice. One thing I would like is for all code which implements fixes for low-level stuff that's broken/nonexistent on certain systems be placed in a separate directory (say lib/). Then write everything else (i.e. the important rc code) to a sane interface, and bring in the code that wraps the unsane interfaces inside sane interfaces in as needed. > 20. ~ expansion. I am, of course, biased for this, if only because I haven't actually used ~ for matching in a script yet... Here's my question. Is there really anything about '~' (the builtin) that can't be done with an external program? Why does it get a special glyph indtead of a name like 'match'? I never use '[' for 'test' when i'm using rc... Obviously, you can argue that there's nothing at all essential about using ~ to denote $home, but you have to make a tradeoff somwhere. > 27. Smaller, faster, cheaper. I don't think rc has any major > inefficiencies, but I will certainly throw some profiling tools at > it, to see if there are improvements to be made. In this context, > "cheaper" means smaller to download, or faster to build. Don't forget easier to read (as in source code) -- for those of us struggling to learn. -- Written with 100% free software. Please support the following websites: www.noamazon.com www.eviltoy.com www.debian.org www.gnu.org lpf.ai.mit.edu
> From: Tim Goodwin <tjg@star.le.ac.uk> > the aim is to round off (a very few) rough corners, without adding lots of new features or extra > code. Good. > Point 8 is that you can say this: > fn foo { (x.y) = foo; echo $(x.y) } > and `foo' works fine in the current shell, but not in descendant shells. IMHO, that is definitly a bug. > I claim that $path and friends should not be exported by rc, nor > (ever) interpreted by descendant rc processes. I interpret this to mean that each rc process sets $path from $PATH upon start-up, and then tracks changes to $path over to $PATH. $PATH is then exported to descendant rc processes. Correct? > `.' should search `$path' ... > [because] every other shell does, including (I'm told) the Plan 9 rc. Iff Plan9 rc does, then ok (grudgingly :-) > 17. Improved error reporting, ...deleted > rc: `host' not found Looks fine to me. > 19. Discard autoconf and automake. > This deserves a separate thread. Please start it. Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.''
> Interesting. The docs for Plan 9 rc indicate that that's true, going > back to the version in the printed 10th edition manuals. As do sh and > its descendents, though not the csh family. According to Chet Ramey, > Posix mandates path searching for ``.'' in csh. I assume you mean `sh' here. POSIX.2, section 3.14.4. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet) Chet Ramey, CWRU chet@po.CWRU.Edu http://cnswww.cns.cwru.edu/~chet/
> From: Paul Haahr <haahr@jivetech.com> > Posix mandates path searching for ``.'' in sh. > But Byron's rc never has, and I don't think it should. Agree.
> From: Paul Haahr <haahr@jivetech.com> > > Decklin Foster wrote: > > 20. ~ expansion. > > I am, of course, biased for this, if only because I haven't actually > > used ~ for matching in a script yet. I use it in 1 out of 2 sripts. All that have -a style arguments.
Paul wrote:
> Adding it to print.c would be problematic, I think, because there's no
> distinguished function for printing errors.
No big deal. If there are going to be any changes, then I think there
should be a clear distinction, during discussion, between those which
affect behaviour, and those which affect implementation. As I think I
mentioned earlier, when Tim raised the subject of 2.x, I first took
that to mean an internal reorganisation, rather than an external one.
steve