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

[quanstro@speakeasy.net]

>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