byron’s rc is a superior fork of Tom Duff’s rc shell. It’s always sad to me it’s called the plan 9 shell considering it was largely designed in the research unix v10 manual by td.
Byron fixed some huge ergonomic annoyances of rc:
no more quoting = signs every where because of the plan 9 parser
proper else syntax, instead of this if not crap. Which is ironic considering byron is using the same hack that Go ended up using in it’s parser.
readline/libedit/etc support
I use it as my full time interactive shell, but the real power comes from quoting. I’ve found compatibility with POSIX shell code to be largely not necessary.
The section following this quote is good. The IFS=/ vulnerability for setuid programs is a good one.
The most important principle in rc’s design is that it’s not a macro processor. Input is never scanned more than once by the lexical and syntactic analysis code (except, of course, by the eval command, whose raison d’être is to break the rule)
Oil follows the same principle, which I call static parsing or undecidable parsing – versus the dynamic parsing of Bourne shell and all its derivatives like bash.
(A notable difference is that Oil compatible with POSIX, Bourne shell, ksh, and bash, while rc is not.)
I probably got that idea from rc shell without realizing it, as I remember reading this paper more than 10 years ago.
I also recently picked up Programming Perl (by Christiansen, foy, Larry Wall), and it points out the same issue with shell multiple times:
In Chapter 20 on security:
Perl is easy to program securely because it’s straightforward and self-contained. Unlike most shell programming languages, which are based on multiple, mysterious substitution passes on each line of the script, Perl uses a more conventional evaluation scheme with fewer hidden snags.
I heard Larry Wall say that one of the goals of Perl 6 was to really fix this problem. It doesn’t do dynamic parsing like Perl 5 does.
Also, back in January 2019, I rediscovered a security problem due to dynamic parsing which appears in all Bourne-derived shells (and at least the OpenBSD shell actually patched it, not sure about bash):
I love rc for shell programming, but as an interactive shell (even in the various currently-existing forks) it’s long been overtaken in features. I’ve long wished for a shell I’ve informally called zrc: the syntax and programming features of rc with the interactive usability of zsh (or even better, the usability of fish). Some day, I hope!
Have you considered using rc within something that is not a traditional terminal emulator?
Most folks who use rc use it within acme. I personally use it within emacs. Once you are depending on a larger editing tool for things like completion, copy pasta, etc and not just readline, you care less about what you were missing from zsh.
This wrapping environment is why a lot of folks don’t care to change much of rc’s interactive experience.
byron’s rc is a superior fork of Tom Duff’s rc shell. It’s always sad to me it’s called the plan 9 shell considering it was largely designed in the research unix v10 manual by td.
Byron fixed some huge ergonomic annoyances of rc:
=signs every where because of the plan 9 parserelsesyntax, instead of thisif notcrap. Which is ironic considering byron is using the same hack that Go ended up using in it’s parser.I use it as my full time interactive shell, but the real power comes from quoting. I’ve found compatibility with POSIX shell code to be largely not necessary.
The section following this quote is good. The
IFS=/vulnerability for setuid programs is a good one.Oil follows the same principle, which I call static parsing or undecidable parsing – versus the dynamic parsing of Bourne shell and all its derivatives like bash.
(A notable difference is that Oil compatible with POSIX, Bourne shell, ksh, and bash, while rc is not.)
I probably got that idea from rc shell without realizing it, as I remember reading this paper more than 10 years ago.
I also recently picked up Programming Perl (by Christiansen, foy, Larry Wall), and it points out the same issue with shell multiple times:
In Chapter 20 on security:
Although this is not entirely true, because there are corners of Perl that have undecidable parsing.
I heard Larry Wall say that one of the goals of Perl 6 was to really fix this problem. It doesn’t do dynamic parsing like Perl 5 does.
Also, back in January 2019, I rediscovered a security problem due to dynamic parsing which appears in all Bourne-derived shells (and at least the OpenBSD shell actually patched it, not sure about bash):
http://www.oilshell.org/blog/2019/01/18.html#a-story-about-a-30-year-old-security-problem
https://github.com/oilshell/blog-code/tree/master/crazy-old-bug
The guy who discovered ShellShock in 2014 wrote a few of the StackOverflow answers there.
plug: tell me what you think of Oil’s syntax :)
I love
rcfor shell programming, but as an interactive shell (even in the various currently-existing forks) it’s long been overtaken in features. I’ve long wished for a shell I’ve informally calledzrc: the syntax and programming features ofrcwith the interactive usability ofzsh(or even better, the usability offish). Some day, I hope!Have you considered using rc within something that is not a traditional terminal emulator?
Most folks who use rc use it within acme. I personally use it within emacs. Once you are depending on a larger editing tool for things like completion, copy pasta, etc and not just readline, you care less about what you were missing from zsh.
This wrapping environment is why a lot of folks don’t care to change much of rc’s interactive experience.
If you’re ever so inclined, I imagine a video or blog post explaining your routine with rc in Emacs would go over well here. :)