4 ms·

After having some experience trying to write portable Bourne Shell scripts, I recently came across Tom Duff's paper[1] describing the "rc" shell used by Plan 9.

After having some experience trying to write portable Bourne Shell scripts, I recently came across Tom Duff's paper[1] describing the "rc" shell used by Plan 9. I was quite blown away by the number of common shell-scripting problems it solves, and the elegance of the resulting language. There's no chance of it replacing, say, Python, but I'm sorely tempted to install Plan 9 From User Space and try out rc the next time I need to script something. [1]: http://doc.cat-v.org/plan_9/4th_edition/papers/rc http://doc.cat-v.org/plan_9/4th_edition/papers/rc

p9idf 15y ago
Erik Quanstrom has a version which fixes some of Rc's faults, like having no return statement and the weird ifs behaviour.
- uriel 15y ago
  The lack of return statements is rarely missed, although it could be handy in some cases, there are ways around it. There is nothing weird about ifs' behavior once you understand it. Byron's rc tried to 'fix' ifs, and made everything worse.
uriel 15y ago
rc is a truly beautiful thing. I wrote a pretty complex web framework and CMS with it ( http://werc.cat-v.org http://werc.cat-v.org ), and the more I used it, the more I loved it. I found it to be extremely well crafted, with every feature fitting beautifully with the rest, it misses many fancy things people expect, but once you know your way around what it has, you can do almost anything. Like awk, is one of those few languages that you can fully keep in your head, and that plus the power of calling other Unix/Plan 9 commands makes it very effective.
- rednaught 15y ago
  Thanks for creating that framework. I had seen it in use a few times but it didn't dawn on me until reading your comments above the relation to Plan 9.
guns 15y ago
I was intrigued by your comment and took a look at the rc feature list, but I couldn't see any features that aren't available in bash 3.1 and above. This takes nothing away from rc of course, which was around when bash was a simple re-implementation of sh, and may very well have been the inspiration for some of bash's modern features. [1] With regards to scripting, since perl/python/ruby has supplanted shell for moderate to difficult tasks, I think it's perfectly reasonable to use bash/zsh for the occasional simple shell script. Arch Linux, for example, writes rc scripts in modern bash, significantly increasing legibility (given you can read modern bash). Even if you stick to sh for maximum portability, if you use bash/zsh as an interactive shell, I would strongly encourage diving into the man page; modern shells, for all their shell\ quoting woes, have an amazing amount of concise constructs that make life at the command line quite pleasurable. [1]: More likely is that Korn shell is the inspiration for both
- p9idf 15y ago
  The main feature that Rc has which Bash lacks is simplicity. Bash's man page is twice the size of Rc's entire source code.
- anon_d 15y ago
  rc solves problems with sh by replacing annoying/problematic features. bash adds the same features, but keeps all the problems with sh. Read the "Design Principles" section for specific examples.
- sigil 15y ago
  I'm not an rc expert, merely a disgruntled POSIX shell scripter, so here are some attractive rc features [1] missing from sh and bash: > Rc captures command exit status in the variable $status. For a simple command the value of $status is just as described above. For a pipeline $status is set to the concatenation of the statuses of the pipeline components with | characters for separators. Both bash and ksh have the pipefail option, which at least makes the pipeline fail if any component fails. (Horrifyingly, POSIX sh lacks even this.) Actually seeing which component failed can be really handy. In other shells, you only get $?. > Arbitrary file descriptors may be sent through a pipe by typing, for example, "vc junk.c |[2] grep -v ’^$’" This deletes blank lines from the C compiler’s error output. POSIX sh, bash, and ksh can only connect stdout to stdin across a pipe. Connecting arbitrary descriptors is nice, particularly in logging applications. > There is no need for the distinction between $* and $@. There is no need for four types of quotation, nor the extremely complicated rules that govern them. How many people understand the difference between $* and $@ in POSIX sh or bash, or for instance the difference between "$@" and $@? These are critical things any POSIX shell scripter should know, yet I've met very few that actually do. One approach is to educate people about these things. Another is to avoid the need to educate them in the first place. I like that rc cleans up quoting, which I've seen single-handedly scare developers off of shell scripting. [1] http://doc.cat-v.org/plan_9/4th_edition/papers/rc http://doc.cat-v.org/plan_9/4th_edition/papers/rc

p9idf 15y ago

Erik Quanstrom has a version which fixes some of Rc's faults, like having no return statement and the weird ifs behaviour.

uriel 15y ago
The lack of return statements is rarely missed, although it could be handy in some cases, there are ways around it. There is nothing weird about ifs' behavior once you understand it. Byron's rc tried to 'fix' ifs, and made everything worse.

uriel 15y ago

rc is a truly beautiful thing. I wrote a pretty complex web framework and CMS with it ( http://werc.cat-v.org http://werc.cat-v.org ), and the more I used it, the more I loved it. I found it to be extremely well crafted, with every feature fitting beautifully with the rest, it misses many fancy things people expect, but once you know your way around what it has, you can do almost anything. Like awk, is one of those few languages that you can fully keep in your head, and that plus the power of calling other Unix/Plan 9 commands makes it very effective.

rednaught 15y ago
Thanks for creating that framework. I had seen it in use a few times but it didn't dawn on me until reading your comments above the relation to Plan 9.

guns 15y ago

I was intrigued by your comment and took a look at the rc feature list, but I couldn't see any features that aren't available in bash 3.1 and above. This takes nothing away from rc of course, which was around when bash was a simple re-implementation of sh, and may very well have been the inspiration for some of bash's modern features. [1] With regards to scripting, since perl/python/ruby has supplanted shell for moderate to difficult tasks, I think it's perfectly reasonable to use bash/zsh for the occasional simple shell script. Arch Linux, for example, writes rc scripts in modern bash, significantly increasing legibility (given you can read modern bash). Even if you stick to sh for maximum portability, if you use bash/zsh as an interactive shell, I would strongly encourage diving into the man page; modern shells, for all their shell\ quoting woes, have an amazing amount of concise constructs that make life at the command line quite pleasurable. [1]: More likely is that Korn shell is the inspiration for both

p9idf 15y ago
The main feature that Rc has which Bash lacks is simplicity. Bash's man page is twice the size of Rc's entire source code.
anon_d 15y ago
rc solves problems with sh by replacing annoying/problematic features. bash adds the same features, but keeps all the problems with sh. Read the "Design Principles" section for specific examples.
sigil 15y ago
I'm not an rc expert, merely a disgruntled POSIX shell scripter, so here are some attractive rc features [1] missing from sh and bash: > Rc captures command exit status in the variable $status. For a simple command the value of $status is just as described above. For a pipeline $status is set to the concatenation of the statuses of the pipeline components with | characters for separators. Both bash and ksh have the pipefail option, which at least makes the pipeline fail if any component fails. (Horrifyingly, POSIX sh lacks even this.) Actually seeing which component failed can be really handy. In other shells, you only get $?. > Arbitrary file descriptors may be sent through a pipe by typing, for example, "vc junk.c |[2] grep -v ’^$’" This deletes blank lines from the C compiler’s error output. POSIX sh, bash, and ksh can only connect stdout to stdin across a pipe. Connecting arbitrary descriptors is nice, particularly in logging applications. > There is no need for the distinction between $* and $@. There is no need for four types of quotation, nor the extremely complicated rules that govern them. How many people understand the difference between $* and $@ in POSIX sh or bash, or for instance the difference between "$@" and $@? These are critical things any POSIX shell scripter should know, yet I've met very few that actually do. One approach is to educate people about these things. Another is to avoid the need to educate them in the first place. I like that rc cleans up quoting, which I've seen single-handedly scare developers off of shell scripting. [1] http://doc.cat-v.org/plan_9/4th_edition/papers/rc http://doc.cat-v.org/plan_9/4th_edition/papers/rc