Plan9 has been forked: 9front
ninetimes.cat-v.org
ninetimes.cat-v.org
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
> 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.
thankfully truly posix stuff doesn't have it
No. If you run an external command from an rc script, ie the shell is doing the fork and exec for you, then $status will have a single number just like $?.
It doesn't matter if the external command is an rc script that, internally, runs a pipeline at the end. You will only get a multi-status if the previous statement within the current rc script was a pipeline. Under sh, bash, or ksh, people rarely bother to look at $? in this situation, since it's either potentially irrelevant (without -o pipefail), or you don't know which program it's from (with -o pipefail).
so you call one command and want just to know if it failed
This works perfectly fine in rc:
find . | grep '[0-9]' | wc || echo >[1=2] "number files not found"
> Any $status containing only 0’s and |’s has boolean value true. Any other status is false.
There is nothing weird about ifs' behavior once you understand it.
Byron's rc tried to 'fix' ifs, and made everything worse.
I wrote a pretty complex web framework and CMS with it ( 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.
Heh, seriously, 9front development is done more in fun than anything else, but the 3 main developers are sufficiently talented that rapid progress is being made in several areas where most 9fans tend to struggle. Not only that but 9front's developers seem to be very good at avoiding getting bogged down in peripheral features which divert effort from the drivers and cleanups which Plan 9 really needs.
The native Go integration was a really good move; a lot of interested cross-overs I am sure from the Go community will get into 9front because of that attractive piece.
A couple of years down the road, it would be delightfully perverse to end up with Plan 9 running in the server room and Linux/OSX on the devs' desktops. Maybe unlikely, but fun to consider.
I don't know if they are there quite yet. It seems to me that they still strongly incentivize shipping products and making things people will use within in their corporate culture. I might be wrong. There could be a light coming on.
How many emails/comments/posts EXACTLY like what you just wrote happened in 1991?
No one is saying what Plan9 will or won't become, but that also means you have no idea where it is going in 10 years or what fun innovations will come out of it.
Don't make a habit of shitting on people thinking outside the box, you'll miss a lot of interesting things.
It's not GPL-compatible, but it's definitely Free.