A new beta release, rc-1.6b3, is available from the usual place. http://www.star.le.ac.uk/~tjg/rc/beta/rc-1.6b3.tar.gz Please test this beta! I'd like to turn it into rc-1.7, but it needs a lot more testing first. I need positive feedback (platforms where it builds and runs smoothly) as well as reports of any problems. The NEWS file from this release is appended: it describes significant changes since the rc-1.6 full release. Further details are in the ChangeLog file in the distribution, and even more details can be found on my new "hacking notes" page; anyone who is, or would like to be, familiar with rc's internals is encouraged to look at this page. http://www.star.le.ac.uk/~tjg/rc/misc/notes The only major missing feature that I'm aware of is support for the 4.4 BSD libedit. This is planned, but probably not till after rc-1.7. Tim. Highlights of changes since rc-1.6. See ChangeLog for further details. Portability. Many minor tweaks, including fixes for BeOS, CygWin, and gcc-3. Bug fixes. A number of bugs have been fixed. The serious ones were: a core dump, triggered by `~ () '*''; premature exit, triggered by sourcing a file which could be open()ed but not read() (such as a directory on many systems); uninterruptible looping, triggered by semantic errors in `fn prompt'. New features. The following features are new: the `$version' variable replaces the `-V' flag; the `-I' flag (definitively not interactive) was added for compatibility with the Plan 9 rc; ASCII SOH (^A) is now handled transparently. Documentation. Distributions of this rc used to include a PostScript paper given by Tom Duff to the UKUUG, describing the Plan 9 rc. This paper is no longer distributed with rc, but instead is available on the web, both in its original PostScript version, and an updated HTML version. Tim Goodwin 2001-10-05
On Monday 15 October 2001 15:56, Tim Goodwin wrote: > A new beta release, rc-1.6b3, is available from the usual place. Thanks. > Please test this beta! I'd like to turn it into rc-1.7, but it needs > a lot more testing first. I need positive feedback (platforms where > it builds and runs smoothly) as well as reports of any problems. Suse Linux 7.2 with a CVS gcc-3.1 from last week does fine. But there are some issues, not version dependant, that I don't understand. This will get out of control: ; fn l {ls -l $*} ; fn l {l -a $*} ; l And what about job control, how do I handle that? Thanks, Buggs
> Suse Linux 7.2 with a CVS gcc-3.1 from last week does fine. Thanks for the report. (Keep 'em coming, folks!) > But there are some issues, not version dependant, that I don't understand. > This will get out of control: > > ; fn l {ls -l $*} > ; fn l {l -a $*} > ; l Your function `l' always calls itself recursively, so it rapidly runs out of stack. Remember that, unlike other shells, rc is not a macro processor. In particular, the `l' in the function body of your second definition is *not* expanded using the previous definition of `fn l'. (You can always use `whatis' to see the current definition of a function.) A simple fn l { ls -la $* } is probably what you want. Also, check out the `builtin' builtin, which allows a function to call a builtin or external command of the same name without recursing: fn ls { builtin ls -F $* } > And what about job control, how do I handle that? This shell does not have job control. It has been said (by Duff? Pike? Rakitzis? I forget...) that job control adds a deal of complexity to handle just the easy part of a hard problem. The suggested alternative in a windowing environment is to open a new window. If you're not in a windowing environment, you might like the `screen' program, which does both the easy and hard parts of the problem. There's also a "tabbed" version of gnome-terminal around, called `multignometerm'. Tim.
On Wednesday 17 October 2001 15:34, Tim Goodwin wrote: > > Suse Linux 7.2 with a CVS gcc-3.1 from last week does fine. > > Thanks for the report. (Keep 'em coming, folks!) Your welcome. I migth be able to provide a few others next week. > > But there are some issues, not version dependant, that I don't > > understand. This will get out of control: > > > > ; fn l {ls -l $*} > > ; fn l {l -a $*} > > ; l > > Your function `l' always calls itself recursively, so it rapidly runs > out of stack. Thougth so. > Remember that, unlike other shells, rc is not a macro processor. In > particular, the `l' in the function body of your second definition is > *not* expanded using the previous definition of `fn l'. (You can > always use `whatis' to see the current definition of a function.) So my old definition is lost and it constantly calls itself. > A simple > > fn l { ls -la $* } > > is probably what you want. Yes, probably. But I also wondered about the why of the failure and why I did not receive a warning (could have been a bug after all). [...] > > And what about job control, how do I handle that? > > This shell does not have job control. > > It has been said (by Duff? Pike? Rakitzis? I forget...) that job > control adds a deal of complexity to handle just the easy part of a > hard problem. The suggested alternative in a windowing environment is > to open a new window. I see. That was exactly what I wanted to know, thanks. > If you're not in a windowing environment, you might like the `screen' > program, which does both the easy and hard parts of the problem. > There's also a "tabbed" version of gnome-terminal around, called > `multignometerm'. Never used multignometerm but that is the way KDE's konsole takes, which I can also recommend. Thanks again, Buggs
> rc 1.6b3 builds, makes trip, and runs fine for me. This > is on a PC running Slackware Linux 8.0 (kernel 2.4.12, > 2.2.3). Haven't done any exotic testing but I'm using > it as my login shell with no problems. Thanks for the report. Incidentally, so far the only problem report with rc-1.6b3 was a thinko in the documentation (now fixed). If anybody's discovered any problems at all, *please* let me know. Thanks! > It appears that the consensus > was not to include [the equals hack] in rc, but I wondered if it > could be a build-time option or even a commented line > in parse.y that the user could enable at build time. I'm not sure if there was anything as grand as consensus! I agree with you that it should be available in some way to those that want it; probably as a configure `--with-eq-hack' option or somesuch (although at the same time I'm reluctant to introduce yet more configure options). At the moment, I really want to get rc-1.7 out the door, as it does contain important bug and portability fixes over rc-1.6. When that's done, we can reconsider more exotic things... Regards, Tim.
What, if anything, should we do about large file support?
On Mon, Oct 15, 2001 at 08:56:06AM -0500, Tim Goodwin wrote: > A new beta release, rc-1.6b3, is available from the usual place. > > http://www.star.le.ac.uk/~tjg/rc/beta/rc-1.6b3.tar.gz > > Please test this beta! I'd like to turn it into rc-1.7, but it needs > a lot more testing first. I need positive feedback (platforms where > it builds and runs smoothly) as well as reports of any problems. Mine is not really a bug report, buth rather a request for a new feature. I dunno whether it has been asked before on this list, but are there any chances that rc will ever handle a path specification in the form of: ; command ~/path/to/file where ``~'' gets substituted internally with the value of $home ? Likewise, ~user should be replaced by $home/user/. Of course this is a-la-bash, but it would make rc much more handy to use as a login shell. The executable that I use has been linked with the GNU readline library, which handles the above cases correctly, but when it passes the path to rc the latter complains, of course. bye, carlo -- For easier reading please set the Courier font. Messages larger than 30 KB may not receive immediate attention. Freedom for Business: http://swpat.ffii.org
> Mine is not really a bug report, buth rather a request for a new > feature. I dunno whether it has been asked before on this list, but Trust me: it has been asked before :-). > are there any chances that rc will ever handle [tilde expansion ?] Probably not. Before it could happen, we would need: i) somebody to figure out how tilde expansion can co-exist with rc's existing interpretation of tilde; OR ii) somebody to persuade the tilde expanders of an alternate syntax they are happy with. Note that if you can twist option ii) far enough, rc *already* has tilde expansion :-). ; fn h {if(~ () $1){echo $home}else perl -le 'print ((getpwnam('^$1^'))[7])'} ; echo `h /h/tjg ; echo `{h games} /usr/games You should be horrified at the use of Perl here, so compile the program below as `homedir', and use: ; fn h {if(~ () $1){echo $home}else homedir $1} Cheers, Tim. #include <stdio.h> #include <sys/types.h> #include <pwd.h> int main(int argc, char **argv) { if (argv[1]) { struct passwd *p = getpwnam(argv[1]); if (p) puts(p->pw_dir); } }
On Tue, Oct 23, 2001 at 02:55:57AM -0500, Carlo Strozzi wrote:
> ; command ~/path/to/file
this has been discussed 1000 times, please check
the mail archive.
-m
I'd like to second this. It's the only reason I don't use rc as my
shell, other than that I really like it. Does anybody have a patch?
Sam
Quoting Carlo Strozzi <carlos@scriptaworks.com>, who wrote:
> Mine is not really a bug report, buth rather a request for a new
> feature. I dunno whether it has been asked before on this list, but
> are there any chances that rc will ever handle a path specification
> in the form of:
>
> ; command ~/path/to/file
>
> where ``~'' gets substituted internally with the value of $home ?
> Likewise, ~user should be replaced by $home/user/. Of course this
> is a-la-bash, but it would make rc much more handy to use as
> a login shell. The executable that I use has been linked with the
> GNU readline library, which handles the above cases correctly, but
> when it passes the path to rc the latter complains, of course.
--
Sam Roberts <sroberts@certicom.com>
On Tue, Oct 23, 2001 at 04:47:52PM +0200, Markus Friedl wrote: > On Tue, Oct 23, 2001 at 02:55:57AM -0500, Carlo Strozzi wrote: > > ; command ~/path/to/file > > this has been discussed 1000 times, please check > the mail archive. And another 1000 times it will probably be asked again in the future by another 1000 people who think that such a feature would make sense :-) Joking apart, I like rc very much, also because its supporters are so reluctant about making it a feature-packed shell. I just think that a `--with-tilde-hack' switch at configure time would not require more syntax-tweaking than a `--with-eq-hack' one :-) cheers, carlo -- For easier reading please set the Courier font. Messages larger than 30 KB may not receive immediate attention. Freedom for Business: http://swpat.ffii.org
> I'd like to second this. It's the only reason I don't use rc as my
> shell, other than that I really like it. Does anybody have a patch?
I use "$h" for my home instead of "~". It's a little longer, but not
really harder to type. I use /u/user for home directories, which is easy
if you have an automounter (or Plan 9), and which works with all programs.
It's funny to call the tilde thing "a-la-bash", since it was invented
for csh many years before bash was written.
Mail thru hawkwind is very slow these days; is there a problem?
On Tue, Oct 23, 2001 at 07:44:31AM -0500, Tim Goodwin wrote: (...) > > You should be horrified at the use of Perl here, so compile the I definitely am :-) (...) > int main(int argc, char **argv) { > if (argv[1]) { > struct passwd *p = getpwnam(argv[1]); > if (p) > puts(p->pw_dir); (...) Well, a nice piece of awk would fit equally well here. But apart from that, of course my point was to have rc go well with the GNU realine library (tab-completion and that), and the above does not really fit the bill. On the other hand, one of the nice things abot rc is that it has a small memory footprint, and adding features would make it worse in that respect. I think I'll leave without tilde expansion, and continue to use rc mostly for scripting :-) Thanks anyway, and keep up with the good work. bye, carlo -- For easier reading please set the Courier font. Messages larger than 30 KB may not receive immediate attention. Freedom for Business: http://swpat.ffii.org
| What, if anything, should we do about large file support? In my limited experience and experimentation, it suffixes to compile rc with the right magic option. No actual source code changes seem necessary. The only seeking rc seems to do is in history.c (and that's not to a variable position); it's otherwise pretty uncaring about most of the large file issues. The only reason I recompiled rc with large file support (on Linux) was so that commands could have stdin/stdout redirected from/to large files. I don't know if autoconf et al has a test for large file support. If it does, it might be worth building rc that way automatically. If not, it's pretty easy to add the magic #define (actually usually a -D) by hand. - cks
| On the other hand, one of the nice things abot rc is that it has a | small memory footprint, and adding features would make it worse in | that respect. Tilde expansion is particularly bad in that respect because it drags in a large collection of code from the C library. In extreme cases, it may not be possible to statically link something that uses getpwnam() because the mechanisms for flexible username lookups require runtime loaded dynamic libraries. If you do tilde expansion through the filesystem (for example, via a /u directory full of symlinks from usernames to their real home directory) you can gain the benefit of GNU readline auto-completion as well as significant universality at the price of only a little extra typing. - cks
| The only reason I recompiled rc with large | file support (on Linux) was so that commands could have stdin/stdout | redirected from/to large files. Yes, that's what I had in mind. | I don't know if autoconf et al has a test for large file support. It does. We probably ought to use it.
On Tue, Oct 23, 2001 at 10:34:14PM -0500, Chris Siebenmann wrote: > > If you do tilde expansion through the filesystem (for example, via a > /u directory full of symlinks from usernames to their real home > directory) you can gain the benefit of GNU readline auto-completion as > well as significant universality at the price of only a little extra > typing. Yes, I agree that that is probably the best compromise. I'll revert back to that. thanks, carlo -- For easier reading please set the Courier font. Messages larger than 30 KB may not receive immediate attention. Freedom for Business: http://swpat.ffii.org
I noticed a minor problem in the Makefile.in for people who will be rebuilding the parser with yacc. This is in the rule for parse.c near the bottom of the file, that you must comment in to run yacc. Lines 526-527, once you remove the leading '#' sign, begin with spaces instead of the tab character that Make likes. If you uncomment these lines without changing the tabs to spaces, you get this error from make: Makefile:526: *** missing separator. Stop. I imagine this will be one of your easier bug fixes... Gary -- Gary Carvell gcarvell@wirefire.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp