Re: wishlist

[John (Most modern computers would break if you stood on them) Mackin <john@ civil.su.oz.au>]

I'm quoting Malte.

    [...] I wouldn't bother if here string were removed because I don't
    use them anyway.

[He basically supports here strings, though.]  The point all the here-string
bashers are missing is that here strings are ESSENTIAL.  Quite apart from
arguments from NCARGS, which will doubtless be shot down on the grounds
that ``echo is a builtin'' (not in _my_ rc it isn't!!), the point is that
here _documents_ are convenient (I don't hear anyone arguing that here
documents should be ditched), and rc needs here strings in order to
export functions containing here documents!  Yes?  Try exporting a
function using a here document sometime using a Pike sh.  Make
sure you have something to vomit into handy.  And for the curious,
the very last sentence of the Plan 9 rc manual entry is:

	Functions that use here documents don't work.

Is that what you'd rather have?  Here strings stay.

    [Referring to a proposal to ditch ``:]
    Yes, this will surely simplify the parser, but in my experience simplicity
    is not the ultimate goal. In a real worlds shell you have to watch for
    conveniencies, too.

This is precisely, 100%, absolutely on-target!  We don't want a shell we
can prove theorems about.  We want a shell that is _nice to use._  Everything
should be made as simple as possible, _and no simpler._  Oversimplifying
leads to, as Byron once put it very well, a ``Bell Labs pissing contest.''
We don't pursue minimalism for its own sake.  We pursue it for _our_ sakes.
There are still some of us -- probably everyone on this list -- who believe
that software bloat is bad, and that smaller, faster code is better.  That
doesn't mean that we want to edit text files using "cat >" (I'm typing
this in sam :).

    Whenever I try to persuade people to use rc, after a while they'll
    complain about too much typing because of oversimplified quoting
    rules.

I don't know who these people are, or what kind of people they are,
but if that's how they think I am inclined to think that their opinions
are valueless, since they have no taste in software.  rc's quoting rules
are just about the best thing about the whole damn design, along with
the `this is not a macro language, there is no rescanning' paradigm.
I have heard many complaints directed at rc since mid-1991 when I
first started proselytising about it, but this one (that the quoting
rules are too simple) has _never_ been among them.  I think you have
just shown the shell to some very, very weird people.  Let me guess --
they edit with emacs, yes?

    That's why I asked for backslash escapes.

Happily, you didn't and won't get them.  With luck, Paul will throw them
out of es in the current pruning drive (plug plug :).

    I like the "``" mechanism very much.

So do I.  Its convenience certainly justifies its redundancy many times
over.  It must stay.  Why are people looking for features to throw out
of rc, anyway?  It isn't too big.  This whole discussion started with
Tom pointing out features that _should not be added_, changes that
_shouldn't_ be made.  IMNSHO, design-wise, Byron's rc is very, very
close to perfect right now.  There's no need to look for things to
take out.

    	(d) newpgrp: use a wrapper around rc

    You'll loose the history list when using readline or editline.

newpgrp is just an essential builtin in a non-job-control shell that
lives in a job-control world.  Really.

    And another thing that hasn't been discussed here: What about compatibility
    with plan 9 rc ?

This is a big, big issue (in my mind, anyway, I don't know how others feel).
The way I see it, Byron has improved on Duff's design very substantially.
I can't speak to quality of implementation, since I have never read
Duff's sources (although I now have legal access to them), but Byron's
sources are roughly twice as many characters as Duff's.  I don't think
that is in any way indicative that Byron's version is twice as complicated,
since Byron's rc is a rock-solid, production-quality _portable Unix
program_.  Duff's rc is a Plan 9 program.  Like most Plan 9 native
programs, you might even be lucky if you can compile it with a
non-Plan 9 compiler, and when it comes to true portability, forget it.
Plan 9 programs are not designed or implemented to port to other
than Plan 9.  Yes, I know the title of Duff's paper.  I still claim
his rc will definitely NOT compile and work in anything like the
variety of environments that Byron's will.

Gratuitous back-porting of Plan 9 features into Unix programs _must
be avoided_.  I don't have time to speak to this in detail now,
but the point is, just because something is The Right Thing to
do in the Plan 9 environment does NOT make it The Right Thing
to do in a Unix/X environment.  Plan 9 is nice, but it's Plan 9.
Unix is Unix.  rc scripts for Unix won't port to Plan 9 anyway,
unless they're trivial -- and do you REALLY want to see "if not"
instead of "else"?  Come off it.  Byron has _done the job_.  Let
him fix these last few tiny rough spots and then _that's it_, OK?

Really.  Byron's rc is better than Duff's and certainly isn't
broken.  And we _all_ know what not being broken means when
it comes time to think about fixing...

OK,
John.