From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from munnari.oz.au ([128.250.1.21]) by archone.tamu.edu with SMTP id <22543>; Thu, 4 Jul 1991 05:20:36 -0500 Received: from basser.cs.su.oz by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA26108; Thu, 4 Jul 1991 20:20:11 +1000 (from dhog@basser.cs.su.OZ.AU) Date: Thu, 4 Jul 1991 03:48:41 -0500 From: David Hogan To: Rc mailing list Subject: Re: username expansion, gnu readline, and code bloat In-Reply-To: <9107021725.AA00431@roycroft.adobe.com> Message-Id: <9107041848.17532.out.babuz@cs.su.oz.au> X-Face: 'B4A5xr.&(*ne}8,IvVj2^PS"?tx:^[d%W3qSI-pYcRS4#L]H1avGI62"ufA.",n From: haahr@adobe.com (Paul Haahr) > Date: Tue, 2 Jul 1991 12:25:08 -0500 > To: rc@archone.tamu.edu > Subject: Re: username expansion, gnu readline, and code bloat > > Well, I'll put my vote in. I think username expansion _should_ be in rc. > > Maybe it should be #ifdef'd, but it should be available. As for the > > issue of changing the language, well, username expansion need not change > > the language, merely add to it. > adding to it does change it. #ifdef'ing means there would be different > dialects of the language, which is problematic. if username expansion > does go into rc (which, as i've said, i strongly argue against) it should > go into all versions. So it changes the syntax. But adding GNU readline and job control change the semantics. Should we not either have all versions containing these (to which I would protest) or none? What about the limit builtin? This is only available if the system it was compiled on has Berkeley-style limits. And if you're on SUNos, there's an extra option to limit that you can't get on other systems. What should we do? Should we not remove limit from all versions, by your reasoning? But wait! That's not all! There's also the matter of named pipes and the <{command} syntax: ie, if you don't have named pipes, you can't use this syntax. Thus the language even now isn't the same on all machines! Compared to this, the issue of only providing username expansion on some machines pales into insignificance. > why not > s=/usr/src > man=/usr/local/man > i=/usr/include > and be done with it? why is a ``user'' the appropriate concept for > this group of files. Because someone has to own the files. Most systems have passwd entries at least for man, and maybe source, so you get these for free. [Now we move on to cross products: ] > needed it: so far, twice since i switched to rc as my full-time shell. (six > months or so.) wanted it: a dozen or so times more. often i do an `{ls|egrep} > or somesuch where ^^ would have been far more convenient. Well, you could have used the following trick I just worked out: ; z1=(a b c d) ; z2=(x y z) ; eval echo $z1 ^ '^(' ^ $^z2 ^ ')' ax ay az bx by bz cx cy cz dx dy dz And what could be simpler but to wrap this up in a shell function where it'll always be there, just when you need it? (You can turn the string returned into a list, but this is trivial). Of course, this will break if one of the lists contains strings with spaces in them. If you are worried about that you could always use a single for loop, as follows: foo=() for (i in $z1) foo = ( $foo $i ^ $z2 ) You see, rc doesn't need built in cross products. > > Lets restrict ourselves to putting > > _useful_ features into the shell (such as username expansion -- I use > > this every day) and not some feature that noone will ever need. > > > (2) ranges in variable subscripts > > > (3) backslash escapes > > Both (2) and (3) here are gratuitous changes to the syntax of rc. > you say gratuitous, i say necessary. you say useful, i say code bloat. > you say no one, i say everyone. the truth lies somewhere in between. Not necessary, you can obtain the same functionality without them, as has already been established on this thread.