[9fans] Re: 9base ports to unix (flame of byron's rc)

[9fans] Re: 9base ports to unix (flame of byron's rc)

[quanstro]

i think you missed a few things along the way.

i started using byron's rc version < 1.0 around 1990. maybe earlier.
duff's rc was not avaiable to the public in those days. i really 
appreciated having something better than the bourne or bourne-again
shell to use. byron's rc was no "big mistake".

when byron maintained it, it never had any autoconf stuff. it also
had much simpiler builtins. try downloading rc version 1.4 or 1.2
if those things really bother you. btw: it's not necessiary to build 
with readline. i bet there's only 50 lines of conditional code for that.
my favorite recient boner is $version which can't be overwritten.
bogus.

i think you've missed the some important differences:
        x=()
        ~ x () && echo fu

behaves differently in duff's rc vs byron's rc. this is probablly
unintentional, not having side-by-side versions to bakeoff.

        ~ $#x 0 && echo fu

does the same thing, though. byron's rc doesn't support
unicode (anymore? --- i thought this used to work). e.g.
(sorry about the lack of unicode support thorugh this interace.
<alpha> stands for U+03b1, of course.)
        <alpha> = 1
        echo $<alpha>
      -> syntax error

also, internally duff's rc
responds to signals by popping the vm stack down to the interactive
frame. byron's rc finds a good spot and longjmp()s. this 
requires some goofy memory managment and is very sensitive
to changes in the c library / operating environment, etc.

also, the "if not" vs "else" debate. both of these are hacks to get
around the fact that yacc wants to shift another token when presented
with a c-style if-then-else right after then "then" clause. this is 
a problem for an interactive parser. byron's solution was to not allow 
a newline before the else. duff's was to force a newline and call the
else clause "if not".

also, i (and i believe byron and paul haahr) where under the impression
from the paper that

# duff's rc
if (true){
        if (false) {
                echo wierd
        }
}
if not echo broken

would echo broken. the man page for instance says:

          if not command
               The immediately preceding command must have been
               if(list) command. If its condition was non-zero, the
               command is executed.

i just tried this out and i was wrong all these years.
russ cox's comments about a "gratuitus" change makes a lot of sense.

btw, paul haahr's rc's-lovechild-with-scheme shell es uses
        if {stmts} {stmts2} ...
which is just syntatic sugar for
        {stmts} && {stmts2} ...


erik

-----

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

Re: [9fans] Re: 9base ports to unix (flame of byron's rc)

[Anselm R. Garbe]

On 8/20/05, quanstro@speakeasy.net <quanstro@speakeasy.net> wrote:
> i started using byron's rc version < 1.0 around 1990. maybe earlier.
> duff's rc was not avaiable to the public in those days. i really
> appreciated having something better than the bourne or bourne-again
> shell to use. byron's rc was no "big mistake".

I didn't said that byron's rc as a project was a mistake, but the
decisions to make things different from the original rc paper and
still calling it "rc" was a mistake.

> when byron maintained it, it never had any autoconf stuff. it also
> had much simpiler builtins. try downloading rc version 1.4 or 1.2
> if those things really bother you. btw: it's not necessiary to build

I know those versions, because I actually started my fork with brc 1.4
from 92/93 to get a better starting point for the autoconf removal.
But in the meantime several bugs were fixed, thus most portions of the
code I put into rci were from brc 1.7.1 (nearly ~90%). And also I
removed about ~1500 lines of code.

> with readline. i bet there's only 50 lines of conditional code for that.

That's true. The readline dependency wasn't that a big deal and users
might like the autocompletion stuff. But I use rc for scripts and with
such POV there's no justification for readline dependencies - and I
must admit, that it is done right in Plan9, the terminal is
responsible for the history and since all binaries are available in
/bin there's also no real need for autocompletion (which bastardizes
in more "powerful" shells like zsh in the meantime to additional
complexity like autoguessing and completing arguments to programs)...

> i think you've missed the some important differences:
>         x=()
>         ~ x () && echo fu
> 
> behaves differently in duff's rc vs byron's rc. this is probablly
> unintentional, not having side-by-side versions to bakeoff.
> 
>         ~ $#x 0 && echo fu

Dunno, never used such syntax. Looks odd to me.

> does the same thing, though. byron's rc doesn't support
> unicode (anymore? --- i thought this used to work). e.g.

Anymore? Which *NIX tool did ever support unicode? I know of none,
even today there's no Unix tool which really supports UTF8. Those UTF8
locales in Linux are a joke, and these Mozilla workaround are just
insane.

> responds to signals by popping the vm stack down to the interactive
> frame. byron's rc finds a good spot and longjmp()s. this
> requires some goofy memory managment and is very sensitive
> to changes in the c library / operating environment, etc.

I rarely understood the intention of his longjmp tricks.

> also, the "if not" vs "else" debate. both of these are hacks to get
> around the fact that yacc wants to shift another token when presented
> with a c-style if-then-else right after then "then" clause. this is
> a problem for an interactive parser. byron's solution was to not allow
> a newline before the else. duff's was to force a newline and call the
> else clause "if not".

I agree that both solutions are hacks, but I argued about the rc
"standard" defined in Duff's paper. If integral parts like condition
handling are different, then Byron's shell cannot be called "rc", even
if the original implementation was not available by that time is no
excuse, because the paper has been available for the whole time.

And actually I don't really believe that Byron had no access to the
original rc source, because he mentions several times similarities to
10th Ed rc, especially in the yacc file.

> # duff's rc
> if (true){
>         if (false) {
>                 echo wierd
>         }
> }
> if not echo broken
> 
> would echo broken. the man page for instance says:
> 
>           if not command
>                The immediately preceding command must have been
>                if(list) command. If its condition was non-zero, the
>                command is executed.
> 
> i just tried this out and i was wrong all these years.

I'm not surprised, because even a shell interpreter works on a stack
and thus "knows" scopes.

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

Re: [9fans] Re: 9base ports to unix (flame of byron's rc)

[Axel Belinfante]

> > does the same thing, though. byron's rc doesn't support
> > unicode (anymore? --- i thought this used to work). e.g.
> 
> Anymore? Which *NIX tool did ever support unicode? I know of none,
> even today there's no Unix tool which really supports UTF8.

I don't know whether they count as Unix tools, nor whether they
'really supported UTF8' but I've always believed that (matty's)
9term(*) and wily and tcs did unicode. sam too, I think.
a README.unicode from 9term from around 1993 convincly suggests this.

Axel.

Re: [9fans] Re: 9base ports to unix (flame of byron's rc)

[Anselm R. Garbe]

On 8/20/05, quanstro@speakeasy.net <quanstro@speakeasy.net> wrote:
> well the gentoo folks should have consulted you before deciding
> to name their init script /sbin/rc. see this bug for some humor:
> http://bugs.gentoo.org/show_bug.cgi?id=45183

Fun :)

> you've also got to realize that in 1990 linus and tannenbaum were still
> duking it out. nobody had any idea that plan9 stuff would actually be
> available to the public. byron's rc would not have been written if
> that had been the case.

Sure.

> > Anymore? Which *NIX tool did ever support unicode? I know of none,
> > even today there's no Unix tool which really supports UTF8. Those UTF8
> > locales in Linux are a joke, and these Mozilla workaround are just
> > insane.
> 
> many unix tools do pretty well with utf-8 (thank's rob, ken. excellent design.)
> do-nothing gets you a long way towards utf-8 support.
> 
> obviously, explicitly single-character-based stuff breaks. but i've been using
> utf-8 for years without any serious problems. sam and 9term have managed
> when other tools (e.g. vi, xterm) were confused.
> 
> in fact, gnu's utf-8 "support" has made things quite a bit worse. unless it's
> been fixed in the last month grep on a fixed ascii string in ascii text is about
> 100x slower in a utf-8 locale because wctomb() is called on each character.

I referred more to the GNU stuff and non-plan9ish tools which
introduced locales instead... but well, there haven't been much tools
except the plan9ish ones which supported utf8 in the 90s already. And
as stated what I've seen so far in the Unix world are many different
approaches which never work well - I investigated some time into the
X11 crap to get UTF8 working, but with very emberassing results (even
public available libraries like libcairo are crashing when processing
UTF8 strings for odd reasons)... there might be hope that this will
change. But I personally consider using libutf9 from plan9 and
libregexp instead of hoping... 9term and sam did similiar
(libXg/libtext dependencies which solved UTF8 very early).

> the grammar was publised in duff's original paper. the "similarities"
> were all based on reading the paper. i don't think you understand how
> restrictive AT&T licensing was at the time.

Ok, that explains the comments especially in the yacc file.

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

[9fans] Re: 9base ports to unix (flame of byron's rc)

[quanstro]

>I didn't said that byron's rc as a project was a mistake, but the
>decisions to make things different from the original rc paper and
>still calling it "rc" was a mistake.

well the gentoo folks should have consulted you before deciding
to name their init script /sbin/rc. see this bug for some humor: 
http://bugs.gentoo.org/show_bug.cgi?id=45183

you've also got to realize that in 1990 linus and tannenbaum were still
duking it out. nobody had any idea that plan9 stuff would actually be
available to the public. byron's rc would not have been written if 
that had been the case.

> must admit, that it is done right in Plan9, the terminal is
> responsible for the history and since all binaries are available in
> /bin there's also no real need for autocompletion (which bastardizes
> in more "powerful" shells like zsh in the meantime to additional
> complexity like autoguessing and completing arguments to programs)...

well, that's a matter of religious conviction. i'm a big fan of rc's history
mechanism. i like rio's history, too. but often i want some command from
some window (don't remember which one) that i typed yesterday.
rio's history doesn't give that to you.

both are unable to cope with commands that span lines.

> > i think you've missed the some important differences:
> >         x=()
> >         ~ x () && echo fu
            ~ $x () && echo fu
> > 
> > behaves differently in duff's rc vs byron's rc. this is probablly
> > unintentional, not having side-by-side versions to bakeoff.
> > 
> >         ~ $#x 0 && echo fu
> 
> Dunno, never used such syntax. Looks odd to me.

sorry about the typo. with rc (either one) test(1) can be replaced by
the (~) operator.

> > does the same thing, though. byron's rc doesn't support
> > unicode (anymore? --- i thought this used to work). e.g.

> Anymore? Which *NIX tool did ever support unicode? I know of none,
> even today there's no Unix tool which really supports UTF8. Those UTF8
> locales in Linux are a joke, and these Mozilla workaround are just
> insane.

many unix tools do pretty well with utf-8 (thank's rob, ken. excellent design.)
do-nothing gets you a long way towards utf-8 support.

obviously, explicitly single-character-based stuff breaks. but i've been using
utf-8 for years without any serious problems. sam and 9term have managed
when other tools (e.g. vi, xterm) were confused. 

in fact, gnu's utf-8 "support" has made things quite a bit worse. unless it's 
been fixed in the last month grep on a fixed ascii string in ascii text is about
100x slower in a utf-8 locale because wctomb() is called on each character.

i think it's safe to say that character sets are going to be a big problem for
years to come. plan9 support has it's problems too.

> I rarely understood the intention of his longjmp tricks.

it's there for one reason: to catch signals. 

> And actually I don't really believe that Byron had no access to the
> original rc source, because he mentions several times similarities to
> 10th Ed rc, especially in the yacc file.

the grammar was publised in duff's original paper. the "similarities"
were all based on reading the paper. i don't think you understand how
restrictive AT&T licensing was at the time.

erik