Re: rc futures

[Decklin Foster <fosterd@hartwick.edu>]

[boy, I'm late replying to this. *don't* ask where i've been...]

Tim Goodwin writes:

> 5. Builtin `echo'.  Well, it's not going away :-). There's always the
> compile-time option to omit it...

We could always make echo an optionally-compile-inable builtin /a la/
the stuff in addon.c, and make the people who want it figure out how
to have it be linked in... ;-) Not that *hard*, just annoying.

> 6. Avoid exporting a variable: see below.

Why do we need this? My apologies if this has already been gone over.
I always thought it was some bizzare sh-ism that I was destined never
to understand...

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

Ooops. I thought, from reading the manpage, that rc updated $PATH if
something set $path and vice versa? I guess this must not be the case.

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

Well, we've had some debate here (and i'm definetly on the `against'
side.) My request is this: bash allows 'source' as a synonym for '.'.
I can make a 'source' function for interactive use, but interactively
I'd just type '.' anyway (it's shorter after all). I just prefer
'source' in shell scripts because it's vastly more readable IMHO.
especially when sourcing a dotfile. And scripts can't pull this
hypothetical function out of my $home/.rcrc, unless i'm mistaken.

> 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.

Great. However, I went to go try to add this and discovered print.c. I
must admit that i'm entirely lost in it. It *seems* to be a copy of
fprintf. Are we actually trying to be portable to systems without a
printf? :-) But seriously, there are some entry points which deal with
this Format structure that i'm not sure of the significance of...

So can anyone lend a hand? I'd really like to grok this code. If you
only reply to one issue in this mail, make it this one.

> 18. Support BSD editline, and clean up the readline, editline, vrl, etc.
> interface if possible.  (Suggestion due to Raymond Venneker.)

also a more (intellegent, bloated, take your pick... ;-)) readline
interface. with bash readline can look inside variables and complete
against $PATH if it's the first word, and so on... If I can figure out
how to help with #17 and it gets fixed then I'll take a look at this.
Don't worry, i'll ask if I have to add anything *really* fattening.

> 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.

That'd be nice. One thing I would like is for all code which implements
fixes for low-level stuff that's broken/nonexistent on certain systems
be placed in a separate directory (say lib/). Then write everything
else (i.e. the important rc code) to a sane interface, and bring in
the code that wraps the unsane interfaces inside sane interfaces in as
needed.

> 20. ~ expansion.

I am, of course, biased for this, if only because I haven't actually
used ~ for matching in a script yet... Here's my question. Is there
really anything about '~' (the builtin) that can't be done with an
external program? Why does it get a special glyph indtead of a name
like 'match'? I never use '[' for 'test' when i'm using rc...

Obviously, you can argue that there's nothing at all essential about
using ~ to denote $home, but you have to make a tradeoff somwhere.

> 27. Smaller, faster, cheaper.  I don't think rc has any major
> inefficiencies, but I will certainly throw some profiling tools at
> it, to see if there are improvements to be made.  In this context,
> "cheaper" means smaller to download, or faster to build. 

Don't forget easier to read (as in source code) -- for those of us
struggling to learn.

-- 
Written with 100% free software. Please support the following websites:
www.noamazon.com www.eviltoy.com www.debian.org www.gnu.org lpf.ai.mit.edu