2016-09-28
Why I switched to the rc shell
I use Byron Rakitzis's reimplementation of Tom Duff's rc for
Unix as my shell and have for a very
long time. Tom Duff wrote the original version at Bell Labs for
Research Unix Version 10 and then Plan 9; Rakitzis reimplemented
it from scratch in 1991 (maybe 1990) for regular Unixes, which I
believe was shortly after Plan 9 started to get serious buzz in the
Unix geek circles of the time. As I've mentioned recently,
rc in its normal state is a fairly austere shell; it has no job
control and for a long time I didn't build it with readline support.
All of this is background, because in a comment on this entry, db48x asked a good question:
Ah, I see. What motivated you to choose rc?
This is a good question and as it happens there are two answers, the sensible pragmatic answer and the more honest one.
The sensible pragmatic answer starts out with that I switched to
rc what is now a very long time ago, when Unix systems were much
smaller and slower than they are today. This had several big effects
on my environment of the time. First, the broadly available choice
of shells was pretty much limited to a relatively authentic version
of the Bourne shell plus tcsh (or csh if you were crazy). Bash
was not widely available and not widely approved of, because by the
standards of the day it was big and memory hungry and slow. Second,
reading dotfiles off disk and parsing them was slow, especially if
your $HOME was on NFS.
In this environment rc offered a nice collection of attractive
features. It didn't have job control, but neither did the Bourne
shell; you had to put up with tcsh's many quirks to get that. Rc
was small and it had a quite regular language that fixed many of
the quirks and awkward annoyances of classical Bourne, and it also
had the great feature that it exported functions into the environment
and imported them again, so subshells didn't
have to re-parse anything off disk. If you were working in X and
starting new xterms all the time (as I was), this avoided a big
performance hit. In addition, I was extra-biased against readline
editing because I was already using a non-terminal emulator called
9term, which didn't work very
well with readline stuff.
(One attraction of rc was that it was small and lightweight enough
that I could compile and use it everywhere, even on places where I
didn't have root. This would not at all have been true of something
like Bash. Even today I use rc this way on many systems.)
So switching to rc from tcsh cost me job control but got me a
nicer shell language and a faster startup in my environment. Readline
support was at most a wash (I can't remember if tcsh even had
readline support in those days).
The honest answer is that sometimes I run across (Unix) things that
immediately strike me as simply right. The moment I see them I
know that they are what I want to use. I had this reaction to MH when I first encountered it, and I had this reaction
to rc when Byron Rakitzis released his copy and I could actually
use it as my shell. All of the pragmatic reasons were there too,
but I was sufficiently taken with rc that I was willing to give
up job control in order to run it, and I did use job control back
then.
(Using job control was self defense in the days of slow, small
machines; it was a lot faster and light-weight to suspend or
background a process from your shell rather than call up an entire
new xterm plus shell (or at least another screen window).)
PS: Looking back at some historical artifacts suggests that I was
actually using ash
at the time, having switched from tcsh to it. I suspect that I'd
found tcsh too heavy-weight and perhaps not cooperative with
9term. Also, I was more of a Unix purist back in those days and
ash is definitely more of a purist shell than tcsh and csh
(especially for scripting).
(In general I remember that readline was not really approved of by the Unix purists. Neither was job control, for that matter.)