Re: rc futures

[Tim Goodwin <tjg@star.le.ac.uk>]

First of all, Happy New Year to you all!

Thanks to everybody who replied to my message about possible future
directions for rc: it's been great to see the discussion.  I've taken
Paul Haahr's message as a starting point to say more on some points... 

To try to stop the discussion spiralling off into ever longer messages,
I'll initiate separate threads for some of the more controversial items.

> Is there really a need for an rc-2?  After all, what appeals to me most
> about the shell is its perfect minimalism -- adding any new features to
> rc could easily make it worse, not better.

I agree.  I certainly don't intend to tarnish rc's minimalism.  I should
have stressed this more in my first message: the aim is to round off (a
very few) rough corners, without adding lots of new features or extra
code.

To look at it another way, I think rc's most important aspect is that
it is *simple*.  (One reason I use rc is that I know that I know its
quoting rules.  I *think* that I know the sh quoting rules, but that's
not quite the same thing...)  Simplicity exists at a number of levels,
and in most cases there is little conflict between "simple for the
implementor", "simple for the installer", and "simple for the user".
There are a few places, though, where I think I can make rc even
simpler.

Finally, I should have made it much clearer in my original message that
some of the wackier ideas were just "brain storming", and may never come
anywhere near being implemented.

> > 1. The ^A bug.  This will be fixed.
> 
> How?  With es, we use combinations of ^A and ^B,

I've considered a number of ideas, and had settled on using ^A and ^B
(independently: I didn't know that this was how es solved the problem).
I will look at es, and ensure that the rc fix is compatible.

>                                                  but it's at least as
> gross a hack as not allowing ^A.

I disagree here.  I don't see anything gross about using a transparent
encoding.  The ^A bug makes the world "not simple" for the user: you
have a perfectly good tool, except that it happens to fall apart for
certain cases.  It's almost as bad as "sed: line too long".  Do you want
people to use Perl? :-)

> > 8 & 9. Strange handling of parentheses.  I think this can be fixed with
> > some tweaks to the grammar, and probably is worth it.
> > 
> > 12. Extra parentheses around `~' and `!' are syntax errors (you'll
> 
> I don't understand the complaints here. 

My point 12 was bogus, I was rushing.  Ignore it.

Point 8 is that you can say this:

    fn foo { (x.y) = foo; echo $(x.y) }

and `foo' works fine in the current shell, but not in descendant shells.
Again, I think this is a clear case of "not simple" for the user: either
the parent shell should reject the function definition, or it should
work in child shells.

Now, it might turn out that fixing this turns out to be really hard,
in which case I won't bother.  It's not that big a deal.  But I have a
sneaking feeling that this is one of my favourite sort of bugs, where
the bug fix actually makes the code simpler.

> I think there was a good reason for preferring $PATH:  rc invokes a
> sh(1) script which sets $path and then invokes and rc script.  Changing
> this behavior would be a mistake.

A number of people have made the same point.  I agree.  However, given
this, I claim that $path and friends should not be exported by rc, nor
(ever) interpreted by descendant rc processes.

> > 11. `.' should search `$path'.  This will be fixed.
> 
> Why?

Every other shell does, including (I'm told) the Plan 9 rc.

> > 13. Add the `flag' builtin ...
> 
> Why?

I can think of occasions where `flag x +' or `flag e +' would be
marginally useful.  The main reason is to make point 14 work, though.

> > 14. Add a command line flag that means "don't export any variables".
> 
> First, the semantics of this are hardly clear.  What happens when you
> modify a variable which is already in the environment?
> 
> Second, why bother?  What need is there for this?

Well, ever since I've been involved with rc the man page has listed
it as a bug, and there's been discussion on the list about it before.
Personally, I have no war stories, and you're right that it would add a
fair dose of complexity.

Any other opinions?  Does anyone have a real need for this?

> > 15. Fake bidirectional pipes on systems where `pipe()' produces a
> 
> Why bother?  How many times do you find programs that can communicate
> with the previous member of a pipeline by writing to their standard
> input?

It's utterly trivial to do, and there are apparently some Plan 9 scripts
that use it.

> > 16. Make `*' match files beginning with `.' (except `.' and `..', of

A number of people have expressed strong opinions on this one.  In both
directions, of course :-).  I think the status quo prevails.

> > 17. Improved error reporting, 
> 
> Adding the name of the script seems useful for errors reported from
> scripts.

There seems to be general agreement on this point.

>           Adding a ``rc:'' prefix seems a mistake to me.

Can you learn to live with it?  In my job, I reach for strace, truss,
or ktrace *every single day*.  At least 50% of the time it's to find
out information about an error situation which the application knew,
but decided not to bother reporting---and yes, sometimes, it's as
fundamental as not even knowing which application encountered an error.

Stealing Smarasderagd's example, I know which of these I'd rather see.

    ; host microsoft.com
    host not found

    ; host microsoft.com
    rc: `host' not found

Maybe you think those 6 extra characters are ugly.  But they also make
it blindingly obvious what went wrong.

Alternatively, we could discard the notion that error messages are
supposed to help people, and just report every error with "?", or maybe
"A device attached to the system is not functioning".  :-)

> > 19. Discard autoconf and automake.

This deserves a separate thread.

> > 20. ~ expansion.
> 
> If you want to start a holy war, be my guest.

:-)

Actually, I'm not a huge fan of ~ expansion, probably because I've never
never used a shell that supported it.  People seem to like it, but I
think it's far too unwieldy to add to rc.

It's at least possible that I will some day write the utility
getpwnam(1).  With this, you could define

    ; fn h { getpwnam $1 | cut -d: -f6 }

and then say

    ; ls `{h fred}

But I don't suppose those arguing for ~ expansion in the shell think
much of this idea...

> If you want to start a holy war, be my guest.  I use ~-expansion, so I'm
> hardly one to complain about it.

> > 21. Add a command line flag that turns off free carets.
> 
> This seems like a really, really bad idea to me.

You're right.  It was a lousy idea.

> > 23. Dynamically load readline only when rc is about to read from a
> > terminal device.
> 
> Ugh.

Yes, ugh, but... (Separate thread for this one, too.)

Tim.