Re: rc futures

[Paul Haahr <haahr@jivetech.com>]

Decklin Foster wrote:

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

No.  Adding compile-time options is always worse.


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

It does the right thing.  Play with it for a second to see:

  ; path = a b
  b not found
  ; path = (a b)
  ; echo $PATH
  a:b
  ; PATH=x:y
  ; echo $path
  x y
  ; 


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

Adding it to print.c would be problematic, I think, because there's no
distinguished function for printing errors.  (I believe es uses eprint
for that purpose.)  And the important part, source file name and line
number, requires understanding the somewhat more subtle stuff going on
in input.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? :-)

That code is my fault, if I remember properly.  Byron and I were taken
with the notion of the Plan 9 print() and fmtinstall(), and used that
model pervasively.  In particular, function exporting depends on the %T
conversion rules -- see footobar.c:Tconv().

Other difference with the stdio printf family (aside from letting you
install your own formatters), include that it works directly with file
descriptors and is unbuffered.

As to excesses in the NIH department, I'm pretty sure rc used to ship
with its own malloc(), too.  (Sun's malloc was very slow at one point.)

> But seriously, there are some entry points which deal with this Format
> structure that i'm not sure of the significance of...

I suspect you're looking at mprint() which returns a string containing
the formated output, allocated with malloc(), and nprint(), which does
the same with nalloc() allocated memory.


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

I thought making getenv do the right thing was most of the battle here.


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

It got a special character because Tom Duff said it did.  But it can't
be confined to an external program because it uses the globbing rules,
so it needs to distinguish between, say, unquoted * and quoted '*'.

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

It can easily do both.  It does in es, and in several rc variants people
have hacked up.

--p