Re: rc futures

[Paul Haahr <haahr@jivetech.com>]

> You may have noticed that recent releases of rc have changed very
> little; this is because I am aiming to produce a very solid rc-1.7.

That would be great.

> After that, I want to start working towards rc-2.  (Or shall we call it
> ActiveShell 2000? :-)

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.

The bugs you listed as needing fixing seem reasonable, though (as you
pointed out for things like the limit on ;-separated commands on a line
or ``='' not used for assignment) the cure may sometimes be worse than
the disease.


I have some specific comments on your suggestions.

> 1. The ^A bug.  This will be fixed.

How?  With es, we use combinations of ^A and ^B, but it's at least as
gross a hack as not allowing ^A.  (If you do change this, unless you've
got a very good reason, try to make it compatible with es.)

> 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
> have to get rc-1.6b2 to see what this is about).  I suspect that these
> "surprising" special cases can be fixed with minor tweaks to the
> grammar.  (Suggestion due to Bengt Kleberg.)

I don't understand the complaints here.  These are not bugs, IMHO, just
consequences of a simple grammar.  Do not underestimate how complicated
you will make the grammar by changing these.

> 10. `$PATH' versus `$path'.  I think rc should prefer `$path' if both
> are set.  Likewise for `$cdpath' and `$home'.

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.

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

Why?  Who uses ``.'' that frequently that it's an issues?  I think the
files you run with ``.'' are rarely the same programs you want to run
with normal execution rules, so I'd prefer keeping it the way it is.

> 13. Add the `flag' builtin as described in this document.  (I've
> considered a few "improved" versions of this, but I think the original
> specification is pretty much spot on.)

Why?  Duff's rc used flag so that rcinit could be used to implement
startup flag processing.  It was not generally useful, just part of the
bootstrap process -- do you want to change the boot process as well?

> 14. Add a command line flag that means "don't export any variables".
> (Any suggestions for a mnemonic letter?)  This is fairly useless on
> the command line, but in conjunction with `flag' solves bug 6 neatly.
> (Actually, the flag will probably mean "don't export any variables,
> except those set in temporary assignments", which is rather more
> useful.)

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?

> 15. Fake bidirectional pipes on systems where `pipe()' produces a
> unidirectional pipe, but `socketpair()' exists.  (Suggestion due to
> Charles Forsyth, via John Murdie.)

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?

> 16. Make `*' match files beginning with `.' (except `.' and `..', of
> course).  This is something of a religious question, but my feeling is
> that special treatment of "dot files" is a mistake.  (Suggestion ditto.)

You will alienate anyone who wants cultural compatibility with normal
Unix shells.  Compatibility with plan 9 is much less important, I think,
than matching Unix users' expectations, especially those of us who've
already been using Byron's rc since 1992.

> 17. Improved error reporting, as discussed on the list recently.  Also,
> I intend that rc should prefix its errors with `rc: '; the long standing
> Unix tradition that shells are special in this regard is not very
> useful, I think.

Adding the name of the script seems useful for errors reported from
scripts.  Adding a ``rc:'' prefix seems a mistake to me.

> 19. Discard autoconf and automake.  I wrote a long message to the
> <9fans> list about some of my objections to autoconf.  I have a
> replacement system in the wings.

I'm not on 9fans, so I missed your note, and I agree that the GNU tools
are big and bloated, but this seems like a waste of time.

> 20. ~ expansion.

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.  I used something
derived from rc which didn't have free carets, and it was mighty
painful.  But percolating that change through the parsing system as a
conditional option seems really unpleasant.

The big problem with free carets is how they affect the implementation
of the shell, and not its usage.  You're proposing to complicate the
implementation for the ``benefit'' of confusion for the end user, who
now has two potential modes to run rc in.

> 23. Dynamically load readline only when rc is about to read from a
> terminal device.  This would mean that a single rc binary would be
> lean and fast for scripts, but still do readline for interactive use.
> However, I suspect that the effort involved in making this happen
> portably would be considerable.

Ugh.


All of these:

> 4. `shift' only works on `$*'. This could be fixed, but it's not hard to
> write a function that can shift any variable (except one).  Suggested
> fix is to the documentation: include the `anyshift' function, and remove
> this "bug".

> 6. Avoid exporting a variable: see below.

> 7. `$^var' to join with an arbitrary separating character.  Again, this
> is easy to fake with a function when needed.

> 24. Make `$ifs' behaviour "smarter".  The problem is that sometimes you
> want repeated separators to indicate a null value, sometimes not. [...]

we ``fixed'' in es.  Yes, they made the shell more general.  Yes,
they're used very occaisionally.  But I'd be surprised to find them
critical to rc.

--p