9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Anselm R. Garbe" <garbeam@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] 9base ports to unix
Date: Fri, 19 Aug 2005 16:10:51 +0200	[thread overview]
Message-ID: <89d1e7b8050819071037b79b55@mail.gmail.com> (raw)
In-Reply-To: <93198fd06809a16f4a19e427e72b0f4e@quintile.net>

On 8/19/05, Steve Simon <steve@quintile.net> wrote:
> Not wishing to troll, but genuine interest - why do you prefer a port
> of plan9's rc to a staticially linked version of Byrons rc rewrite?

Because Byron's rc is not conform to Tom Duff's paper and does very
nasty things, the worst is the totally broken if-else syntax, a
sample:

if(foo) {
}
else {
}

is invalid syntax, only

if(foo) {
} else {
}

is valid syntax (why no if not?), if the else branch is supplied in
Byron's rc reimplementation. Beside of that, Byron's rc introduced
many features like readline() support, history support, clunky
builtins etc., which I removed from the source code (beside other
cleanups, like auto*hell removal, you can find my forked/cleaned up
version, which also implements export here:
http://wmi.modprobe.de/snaps/rci-20050809.tar.bz2 (it is based on
rc-1.7.1)).
Also, Byron's shell implements rc-inconform things like `foo as
abbreviation for `{foo} unless foo is a token which does not contain
whitespaces, or the broken flatten operator $^foo instead of the
correct $"foo. The latter annoyences I fixed in rci, but I wasn't able
to fix the if-else handling, because the broken syntax uses some
common grammar tricks also seen in other interpreters which reflect
into the syntax tree walking, - I didn't wanted to replace the tree
walking code in rc(i), thus I lived with the broken if-else syntax.

> For me there is nothing to chose unless you have a lot of scripts from
> a plan9 system that tickle the changes Byron made. I find the differences
> between Plan9 and Linux sed more of a pain.

I think Bryan did a big mistake when designing his rc
standard-incompliant, because that has been the same issue with
sh-style shells already. I could agree that rfork is complicated, and
I could also accept some extensions, but the base language should be
equal in a shell which states to be rc, but which isn't rc in fact,
only some approximation.

Regards,
-- 
  Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361


  reply	other threads:[~2005-08-19 14:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-19 12:32 Anselm R. Garbe
2005-08-19 13:52 ` Steve Simon
2005-08-19 14:10   ` Anselm R. Garbe [this message]
2005-08-19 19:58     ` Scott Schwartz
2005-08-21 20:16 ` Russ Cox
2005-08-22  6:13   ` Anselm R. Garbe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=89d1e7b8050819071037b79b55@mail.gmail.com \
    --to=garbeam@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).