> Since valgrind[1] came out, I've been applying it to everything I can > think of. rc was pretty clean, with one actual (but minor) problem and > one non-problem. OK, I'll buy both of these. Thanks! And looking again at the signal code, I found a major booboo (of my own making), which pulled in the horrid longjmp() code on systems where it was needed. With this, and some other problems I've fixed, there have been a few changes since rc-1.7. A summary is appended, and please see my hacking page for further details. http://www.star.le.ac.uk/~tjg/rc/misc/notes So, time for a new snapshot. Here it is: http://www.star.le.ac.uk/~tjg/rc/snap/rc-1.7s20020815.tar.gz Tim. 2002-07-25 Bug: fix globbing of broken symlinks. 2002-07-31 Bug: readline doesn't handle EIO either. 2002-08-15 Bug: variables that are sometimes exported (i.e. $prompt and $version) need to be made exportable if they are inherited from the environment. Portability: don't call sigaction() for SIGKILL or SIGSTOP; don't hand a garbage signal mask to sigaction() (thanks Jeremy Fitzhardinge). Also, remove use of SA_INTERRUPT (SUSv3, BSD, etc. have SA_RESTART with the inverted meaning).
Since valgrind[1] came out, I've been applying it to everything I can think of. rc was pretty clean, with one actual (but minor) problem and one non-problem. The actual problem is that it doesn't clear out the sa_mask when calling sigaction, which presumably means that there's a random set of signals masked when calling the signal handler. I'm assuming this isn't a big problem. Maybe it should be sigfillset instead? The non-problem is that it tries to call sigaction on SIGKILL and SIGSTOP. This is ignored by the kernel, but it makes valgrind complain. Here's a patch for both of these: --- rc-1.7/signal.c Thu Nov 1 03:29:10 2001 +++ rc-1.7.jsgf/signal.c Tue Jul 30 23:08:39 2002 @@ -14,6 +14,7 @@ new.sa_handler = handler; new.sa_flags = SA_INTERRUPT; + sigemptyset(&new.sa_mask); sigaction(signum, &new, &old); return old.sa_handler; } @@ -96,6 +97,8 @@ #endif for (i = 1; i < NUMOFSIGNALS; i++) { + if (i == SIGSTOP || i == SIGKILL) + continue; h = sys_signal(i, SIG_IGN); if (h != SIG_IGN && h != SIG_ERR) sys_signal(i, h); J 1: http://developer.kde.org/~sewardj/
> I wish I'd seen this before the release but I haven't been testing them > religiously. Both 1.6c6 and 1.7 hang in make trip in the current directory > globbing on Solaris 2.6 - truss output shows: It's not as serious as you think; rc makes and trips fine on at least one Solaris 2.6 box that I have here. Suggest we take this off the list till we get to the bottom of it. Can you send me the output of `showrev -p' on your failing 2.6 box? Also, are you building on a local filesystem, or NFS, etc? > Does anyone know if there are mailing list archives stored anywhere? There's > no link from the rc home page but I think I've come across it before. There's a couple of list archive files in ftp://ftp.sys.utoronto.ca/pub/rc/ but it only seems to go up to January 2001. Tim.
I wish I'd seen this before the release but I haven't been testing them religiously. Both 1.6c6 and 1.7 hang in make trip in the current directory globbing on Solaris 2.6 - truss output shows: 6477/1: getdents64(3, 0x0005F208, 1048) (sleeping...) Something else is fishy because I can't even connect to the process using adb. /usr/proc/bin/pstack only reports half a stack... ; /usr/proc/bin/pstack 6477 6477: ./rc -p ef739ae0 getdents64 (3, 5f208, 418) ef74c0e8 _readdir64 (0, 0, 0, 0, 0, 0) + bc I have a vague recollection this might be something to do with dodgey large file support on Solaris 2.6 which needs a patch to fix? Apart from that it actually works fine in real life. Also trips fine on FreeBSD 4.5-RELEASE. Does anyone know if there are mailing list archives stored anywhere? There's no link from the rc home page but I think I've come across it before. C Callum Gibson callum.gibson@db.com Global Markets IT, Deutsche Bank, Australia 61 2 9258 1620 ### The opinions in this message are mine and not Deutsche's ###
I'm delighted to announce the release of rc-1.7. Apart from bumping the version number, and a couple of trivial changes to the installation documentation, this release is identical to rc-1.6c7. The release is available from the usual place: http://www.star.le.ac.uk/~tjg/rc/release/rc-1.7.tar.gz and it should also be on the UToronto FTP server soon. I've appended the NEWS file from the distribution, as a reminder of what's changed since rc-1.6. (In summary: not a lot!) A big thank you to everybody who contributed to this release. Tim. Highlights of changes since rc-1.6. See ChangeLog for further details. Portability. Many minor tweaks, including fixes for BeOS, CygWin, QNX, 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'; deficiencies in the `limit' builtin. 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; support for large files; support for more process resource limits. 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 2002-05-21
On Wed, May 22, 2002 at 10:45:10AM -0500, Tim Goodwin wrote:
> A new beta release, which is also a release candidate for the next
> full release, is available from the usual place.
>
> http://www.star.le.ac.uk/~tjg/rc/beta/rc-1.6c7.tar.gz
>
> I've appended the ChangeLog since the last release candidate.
>
> You know the drill: please build and test this on as many systems as
> you have access to. Let me know if it works, and especially if it
> doesn't.
Builds and trips fine on:
FreeBSD hotel.rmta.org 4.6-RC FreeBSD 4.6-RC #2: Thu Jun 6 03:53:29 EDT 2002 i386
gcc version 2.95.3 20010315 release [FreeBSD]
SunOS china.rmta.org 5.5 Generic_103093-28 sun4m sparc SUNW,SPARCclassic
gcc version 3.1
NetBSD spark.rmta.org 1.6A NetBSD 1.6A (SPARK) #5: Tue Jun 4 10:05:33 EDT 2002 sparc
gcc version 2.95.3 20010315 (release) (NetBSD nb2)
--
Scott Kenney >|< saken@hotel.rmta.org
A new beta release, which is also a release candidate for the next full release, is available from the usual place. http://www.star.le.ac.uk/~tjg/rc/beta/rc-1.6c7.tar.gz I've appended the ChangeLog since the last release candidate. You know the drill: please build and test this on as many systems as you have access to. Let me know if it works, and especially if it doesn't. Thanks, Tim. 2002-04-03 Feature: make $version less magical, and exportable if it's changed from its default value. Same for $prompt (thank Erik Quanstrom). Bug: make $bqstatus and $status not exportable. Feature: "stuttering" colons for multiple replacements in the history programs (thanks Callum Gibson). 2002-05-22 Documentation: possible warning in tripping.c (thanks Dan Moniz). Release: rc-1.6c7.
> I would have thought you'd want to export $prompt.
It's exported if it's changed from the default.
The motivation for doing so was this little snippet:
$ env - rc
; printenv
PATH=/usr/local/bin:/usr/bin:/bin:.
prompt=; ^A
No point in cluttering the environment with a value that any
descendant rc process would default to anyway. And since I'd just
invented the mechanism to export $version only if it's assigned to
(all 3 lines of code of it!), I thought I'd use it.
So in the dev version, we get this.
$ env - rc
; printenv
PATH=/usr/local/bin:/usr/bin:/bin:.
; prompt=('rc$ ' '')
rc$ printenv
PATH=/usr/local/bin:/usr/bin:/bin:.
prompt=rc$ ^A
(And even PATH goes away if you build with `--disable-def-path'.)
Tim.
>I would have thought you'd want to export $prompt.
I'd rather have prompt exported as well.
>I've made $prompt act in the same way; I wonder if $ifs should too?
I would have thought you'd want to export $prompt.
What about subshells?
| > Why not just initialize version (provided there's none set in the | > environment?), not export it, and have any assignments turn it into a | > normal variable. I think that's pretty easy to do. | | OK, after a couple of iterations I've now done exactly that. I dunno. In that case calling it rc_version makes more sense to me. Less likely to have accidental collisions.
I want to get rc-1.7 wrapped up in the next couple of weeks. There will be another release candidate (watch this space), but my hope is that it will be the last before the full release. So... if anybody has any outstanding issues with rc-1.6c6, please let me know as soon as possible. Thanks, Tim.
> Why not just initialize version (provided there's none set in the
> environment?), not export it, and have any assignments turn it into a
> normal variable. I think that's pretty easy to do.
OK, after a couple of iterations I've now done exactly that.
I've made $prompt act in the same way; I wonder if $ifs should too?
The other variables to which rc gives default values: $path and $pid;
are never exported.
All this will be in another release candidate soon...
Tim.
Tim wrote > > I'd prefer $rc-version, but either should be fine. > > (As it turns out, this is all irrelevant, but I have would two > objections to this. First, `-' turns on free careting, [...] Yeah, I forgot about that. (We had fixed that in es.) > Secondly, rc is meant to be C-ish, not Lisp-ish.) That, too, we fixed in es. > Mea culpa. I failed to realise that there are two types of special > variable in rc: 1) those that merely have a default initial value, and > 2) those that invoke special code when substituted. Till now, > $version was in category 2. I've just moved it to category 1. This seems quite sensible. > As a separate matter, several variables are not exportable. These > are: $apid, $apids, $cdpath, $home, $ifs, $path, $pid, and $*. > (Remember that $cdpath, $home, and $path are all aliased to upper case > versions, which *are* exportable. Also, the default assignment to > $path happens before $PATH is examined: so if $PATH is set, $path will > acquire its value instead of the default.) > > I think $bqstatus and $status ought to be non-exportable too. I've > just made them so; you can all see what this breaks in the next > release candidate :-). Seems good to me. Three questions: - Is $version exportable? - Is $version exported if the user doesn't assign to it? - Is $version inherited from the environment? --p
Paul Haahr wrote: > > Any objections to `rc_version'? > > I'd prefer $rc-version, but either should be fine. (As it turns out, this is all irrelevant, but I have would two objections to this. First, `-' turns on free careting, so you'd have to say things like this. ; whatis $'rc-version' Not so bad, but wrap it in another level of quotes, perhaps from a less sane shell, and it starts to get *very* ugly. $ rc -c 'whatis $'"'rc-version'" Secondly, rc is meant to be C-ish, not Lisp-ish.) > However, making it such a magic variable feels silly. As Eric noted, > having assignments to a variable just be eaten without warning seems, > er, surprising at best. Mea culpa. I failed to realise that there are two types of special variable in rc: 1) those that merely have a default initial value, and 2) those that invoke special code when substituted. Till now, $version was in category 2. I've just moved it to category 1. Category 2 now contains just $apids and $status, which seems about right; they are both, of necessity, magical. Category 1 now contains $ifs, $path, $pid, $prompt, and $version. (I was surprised to discover that assignments to pid are persistent!) As a separate matter, several variables are not exportable. These are: $apid, $apids, $cdpath, $home, $ifs, $path, $pid, and $*. (Remember that $cdpath, $home, and $path are all aliased to upper case versions, which *are* exportable. Also, the default assignment to $path happens before $PATH is examined: so if $PATH is set, $path will acquire its value instead of the default.) I think $bqstatus and $status ought to be non-exportable too. I've just made them so; you can all see what this breaks in the next release candidate :-). Tim.
On Sat, Mar 30, 2002 at 01:43:31PM -0500, Paul Haahr wrote: > > Why not just initialize version (provided there's none set in the > environment?), not export it, and have any assignments turn it into a > normal variable. I think that's pretty easy to do. This certainly makes sense, I agree. Just forget about my proposed special `rc_' namespace. -cs- -- 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
Tim wrote > Any objections to `rc_version'? I'd prefer $rc-version, but either should be fine. However, making it such a magic variable feels silly. As Eric noted, having assignments to a variable just be eaten without warning seems, er, surprising at best. Why not just initialize version (provided there's none set in the environment?), not export it, and have any assignments turn it into a normal variable. I think that's pretty easy to do. Carlo wrote: > rc already has a few reserved variable names, like $pid, $bqstatus, > $status [...] and my suggestion is to set the `rc_' prefix aside for > rc reserved variables. We would then have rc_path, rc_home, > rc_whatever. Of course, for backward compatibility we will continue to > have also $pid, $path and that, but from now on there whould at least > be a standard for any new rc needs, and that could be documented in > the man page. No! No! No! I understand why one might want to prefix ``version'' -- this is rc's version, not a system-wide version -- but your path, home directory, etc, are exported and global properties. (The path/PATH distinction, etc, is just backwards compatibility, after all.) One of the points of rc is that it uses so few special variables that we don't need special namespaces. --p
On Wed, Mar 27, 2002 at 08:27:16AM -0500, Tim Goodwin wrote: > > is there any way that $version could be changed either > > to not be so magic (i.e. assigned at startup time) or > > better something like _rc_version_. > > The `version' variable was introduced in rc-1.6b1 (replacing the `-V' > flag, which itself was new in rc-1.5b4). Thus, it's never been in a > full release. Thus, I'm prepared to change it :-). > > Any objections to `rc_version'? rc already has a few reserved variable names, like $pid, $bqstatus, $status, and so on. Others, like $version, could be added in the future. It would be nice to have a naming-convention for reserved names, so that one knows in advance what names should be left alone. The proposed `rc_version' is ok, and my suggestion is to set the `rc_' prefix aside for rc reserved variables. We would then have rc_path, rc_home, rc_whatever. Of course, for backward compatibility we will continue to have also $pid, $path and that, but from now on there whould at least be a standard for any new rc needs, and that could be documented in the man page. Since rc supports 'funny' characters in names, the reserved ones could even be 'rc.something', so that they are even more peculiar. Just my two-cent. 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
> is there any way that $version could be changed either
> to not be so magic (i.e. assigned at startup time) or
> better something like _rc_version_.
The `version' variable was introduced in rc-1.6b1 (replacing the `-V'
flag, which itself was new in rc-1.5b4). Thus, it's never been in a
full release. Thus, I'm prepared to change it :-).
Any objections to `rc_version'?
Tim.
is there any way that $version could be changed either to not be so magic (i.e. assigned at startup time) or better something like _rc_version_. i have been discovering scripts that no longer work with rc 1.6 ever since i installed it because they were assigning to $version and expecting the same value back. silly me. erik
> > have also gone down the "twisty little maze of startup files"
> > route; rc will not. Promise.)
>
> Thanks God :-)
I'm not much of a me too guy but
"ME TOO"
by all means offer extra startup stuff as some sort of option but rapid startup time is one of the reasons (among many) I use rc
ta
On Tue, Feb 26, 2002 at 09:16:03PM -0500, Chris Siebenmann wrote: > > Consulting .rcrc for every new shell requires reading and parsing all > of it on every semi-interactive subshell. (The same is true for any > other file rc would be looking at, of course.) > > I spawn a lot of copies of rc over the course of my day. I'm not > really enthused about adding this overhead (and this dependancy on > $home responding right now) to them. I use rc heavily for Web scripting, so it would be even more of a problem. Please do not go that way. 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
On Fri, Feb 15, 2002 at 09:04:36AM -0500, Tim Goodwin wrote: > > 3. Any solution must be simple. If you want zsh, you know where to > find it :-). (The other heavyweight shells, such as bash and tcsh, > have also gone down the "twisty little maze of startup files" > route; rc will not. Promise.) Thanks God :-) -- 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
> Add a flag (say -S) which when used as 'rc -S file' will act as if ". file" > had been the first command executed. I've been thinking of hacking this > into my copy of rc, just so that when starting xterms I can be lasy and > forgo typing '. .rc/interactive' into every new shell. > This could then be used with "ssh -t host 'rc -S startup_file'" from the > originating host if a specific environment set up is required. I quite > _like_ the fact that I can get an virgin environment when logging in > remotely. I am not sure I understand the ssh problem described here. My understanding was that this is a problem with NON-interactive shells. As long as you are willing to play games with wrappers and so on and so forth, why not simply do: rsh foo 'rc -c ''. .rcrc; '$^cmd'''' Incidentally, a good way of getting an interactive shell to do something just once, e.g., when starting a new xterm, is to set fn prompt as follows: fn prompt { fn prompt # remove myself from the environment one-time init stuff } This works differently from .rcrc because it could be, for example, that your .xinitrc runs rc as a login shell, but only when a subshell finally prints a prompt do you do things like set a terminal type, etc. Byron.
> Add a flag (say -S) which when used as 'rc -S file' will act as if ". file"
> had been the first command executed. I've been thinking of hacking this
> into my copy of rc, just so that when starting xterms I can be lasy and
> forgo typing '. .rc/interactive' into every new shell.
>
> This could then be used with "ssh -t host 'rc -S startup_file'" from the
> originating host if a specific environment set up is required. I quite
Even easier, just use ssh -t host 'rc -c ''. startup_file; . -i /dev/stdin'''.