From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from apollo.le.ac.uk ([143.210.16.125]) by hawkwind.utcs.utoronto.ca with SMTP id <25221>; Wed, 5 Jan 2000 18:51:53 -0500 Received: from happy.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 3.03 #1) id 125X1R-0003DY-00 for rc@hawkwind.utcs.toronto.edu; Tue, 04 Jan 2000 16:41:25 +0000 Received: (qmail 21521 invoked from network); 4 Jan 2000 16:42:07 -0000 Received: from ltpcg.star.le.ac.uk (tjg@143.210.36.203) by happy.star.le.ac.uk with SMTP; 4 Jan 2000 16:42:07 -0000 To: rc@hawkwind.utcs.toronto.edu In-Reply-To: Subject: Re: rc futures From: Tim Goodwin Message-ID: Date: Tue, 4 Jan 2000 11:43:12 -0500 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.