From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2408>; Tue, 25 May 1993 05:51:26 -0400 Received: by mod.civil.su.oz.au id <28714>; Tue, 25 May 1993 19:51:08 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Tue, 25 May 1993 05:16:58 -0400 To: The rc Mailing List Subject: Re: wishlist In-Reply-To: <9305250655.AA28604@idefix.techfak.uni-bielefeld.de> Message-ID: <199305251916.16762.rc.bajob@civil.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'm quoting Malte. [...] I wouldn't bother if here string were removed because I don't use them anyway. [He basically supports here strings, though.] The point all the here-string bashers are missing is that here strings are ESSENTIAL. Quite apart from arguments from NCARGS, which will doubtless be shot down on the grounds that ``echo is a builtin'' (not in _my_ rc it isn't!!), the point is that here _documents_ are convenient (I don't hear anyone arguing that here documents should be ditched), and rc needs here strings in order to export functions containing here documents! Yes? Try exporting a function using a here document sometime using a Pike sh. Make sure you have something to vomit into handy. And for the curious, the very last sentence of the Plan 9 rc manual entry is: Functions that use here documents don't work. Is that what you'd rather have? Here strings stay. [Referring to a proposal to ditch ``:] Yes, this will surely simplify the parser, but in my experience simplicity is not the ultimate goal. In a real worlds shell you have to watch for conveniencies, too. This is precisely, 100%, absolutely on-target! We don't want a shell we can prove theorems about. We want a shell that is _nice to use._ Everything should be made as simple as possible, _and no simpler._ Oversimplifying leads to, as Byron once put it very well, a ``Bell Labs pissing contest.'' We don't pursue minimalism for its own sake. We pursue it for _our_ sakes. There are still some of us -- probably everyone on this list -- who believe that software bloat is bad, and that smaller, faster code is better. That doesn't mean that we want to edit text files using "cat >" (I'm typing this in sam :). Whenever I try to persuade people to use rc, after a while they'll complain about too much typing because of oversimplified quoting rules. I don't know who these people are, or what kind of people they are, but if that's how they think I am inclined to think that their opinions are valueless, since they have no taste in software. rc's quoting rules are just about the best thing about the whole damn design, along with the `this is not a macro language, there is no rescanning' paradigm. I have heard many complaints directed at rc since mid-1991 when I first started proselytising about it, but this one (that the quoting rules are too simple) has _never_ been among them. I think you have just shown the shell to some very, very weird people. Let me guess -- they edit with emacs, yes? That's why I asked for backslash escapes. Happily, you didn't and won't get them. With luck, Paul will throw them out of es in the current pruning drive (plug plug :). I like the "``" mechanism very much. So do I. Its convenience certainly justifies its redundancy many times over. It must stay. Why are people looking for features to throw out of rc, anyway? It isn't too big. This whole discussion started with Tom pointing out features that _should not be added_, changes that _shouldn't_ be made. IMNSHO, design-wise, Byron's rc is very, very close to perfect right now. There's no need to look for things to take out. (d) newpgrp: use a wrapper around rc You'll loose the history list when using readline or editline. newpgrp is just an essential builtin in a non-job-control shell that lives in a job-control world. Really. And another thing that hasn't been discussed here: What about compatibility with plan 9 rc ? This is a big, big issue (in my mind, anyway, I don't know how others feel). The way I see it, Byron has improved on Duff's design very substantially. I can't speak to quality of implementation, since I have never read Duff's sources (although I now have legal access to them), but Byron's sources are roughly twice as many characters as Duff's. I don't think that is in any way indicative that Byron's version is twice as complicated, since Byron's rc is a rock-solid, production-quality _portable Unix program_. Duff's rc is a Plan 9 program. Like most Plan 9 native programs, you might even be lucky if you can compile it with a non-Plan 9 compiler, and when it comes to true portability, forget it. Plan 9 programs are not designed or implemented to port to other than Plan 9. Yes, I know the title of Duff's paper. I still claim his rc will definitely NOT compile and work in anything like the variety of environments that Byron's will. Gratuitous back-porting of Plan 9 features into Unix programs _must be avoided_. I don't have time to speak to this in detail now, but the point is, just because something is The Right Thing to do in the Plan 9 environment does NOT make it The Right Thing to do in a Unix/X environment. Plan 9 is nice, but it's Plan 9. Unix is Unix. rc scripts for Unix won't port to Plan 9 anyway, unless they're trivial -- and do you REALLY want to see "if not" instead of "else"? Come off it. Byron has _done the job_. Let him fix these last few tiny rough spots and then _that's it_, OK? Really. Byron's rc is better than Duff's and certainly isn't broken. And we _all_ know what not being broken means when it comes time to think about fixing... OK, John.