rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* Re: rc futures
@ 2000-01-14 12:16 Bengt Kleberg
  0 siblings, 0 replies; 21+ messages in thread
From: Bengt Kleberg @ 2000-01-14 12:16 UTC (permalink / raw)
  To: haahr, tjg; +Cc: rc

> From: Paul Haahr <haahr@jivetech.com>

> Posix mandates path searching for ``.'' in sh.

> But Byron's rc never has, and I don't think it should.

Agree.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
  2000-01-01  4:20   ` Paul Haahr
@ 2000-01-15  8:58     ` Steve Kilbane
  0 siblings, 0 replies; 21+ messages in thread
From: Steve Kilbane @ 2000-01-15  8:58 UTC (permalink / raw)
  To: rc


Paul wrote:

> Adding it to print.c would be problematic, I think, because there's no
> distinguished function for printing errors.

No big deal. If there are going to be any changes, then I think there
should be a clear distinction, during discussion, between those which
affect behaviour, and those which affect implementation. As I think I
mentioned earlier, when Tim raised the subject of 2.x, I first took
that to mean an internal reorganisation, rather than an external one.

steve




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
@ 2000-01-14 12:20 Bengt Kleberg
  0 siblings, 0 replies; 21+ messages in thread
From: Bengt Kleberg @ 2000-01-14 12:20 UTC (permalink / raw)
  To: fosterd, haahr; +Cc: rc

> From: Paul Haahr <haahr@jivetech.com>

> > Decklin Foster wrote:
> > 20. ~ expansion.

> > I am, of course, biased for this, if only because I haven't actually
> > used ~ for matching in a script yet.

I use it in 1 out of 2 sripts. All that have -a style arguments.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
@ 2000-01-12 21:34 Chet Ramey
  2000-01-01  2:55 ` Paul Haahr
  0 siblings, 1 reply; 21+ messages in thread
From: Chet Ramey @ 2000-01-12 21:34 UTC (permalink / raw)
  To: haahr; +Cc: tjg, rc

> Interesting.  The docs for Plan 9 rc indicate that that's true, going
> back to the version in the printed 10th edition manuals.  As do sh and
> its descendents, though not the csh family.  According to Chet Ramey,
> Posix mandates path searching for ``.'' in csh.

I assume you mean `sh' here.  POSIX.2, section 3.14.4.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
@ 2000-01-12 14:22 Bengt Kleberg
  0 siblings, 0 replies; 21+ messages in thread
From: Bengt Kleberg @ 2000-01-12 14:22 UTC (permalink / raw)
  To: rc

> From: Tim Goodwin <tjg@star.le.ac.uk>

>  the aim is to round off (a very few) rough corners, without adding lots of new features or extra
> code.

Good.


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

IMHO, that is definitly a bug.


>  I claim that $path and friends should not be exported by rc, nor
> (ever) interpreted by descendant rc processes.

I interpret this to mean that each rc process sets $path from $PATH
upon start-up, and then tracks changes to $path over to $PATH. $PATH
is then exported to descendant rc processes.
Correct?


> `.' should search `$path'
...
> [because] every other shell does, including (I'm told) the Plan 9 rc.

Iff Plan9 rc does, then ok (grudgingly :-)


> 17. Improved error reporting, 
...deleted
>    rc: `host' not found

Looks fine to me.


> 19. Discard autoconf and automake.

> This deserves a separate thread.

Please start it.



Best Wishes, Bengt
===============================================================
Everything aforementioned should be regarded as totally private
opinions, and nothing else. bengt@softwell.se
``His great strength is that he is uncompromising. It would make
him physically ill to think of programming in C++.''


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
  1999-12-10 16:55 Tim Goodwin
  1999-12-13 18:54 ` Paul Haahr
  1999-12-15  0:17 ` Chris Siebenmann
@ 2000-01-07  3:45 ` Decklin Foster
  2000-01-01  4:20   ` Paul Haahr
  2 siblings, 1 reply; 21+ messages in thread
From: Decklin Foster @ 2000-01-07  3:45 UTC (permalink / raw)
  To: rc

[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


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
  1999-12-13 18:54 ` Paul Haahr
@ 2000-01-04 16:43   ` Tim Goodwin
  1999-12-31 23:26     ` Paul Haahr
  0 siblings, 1 reply; 21+ messages in thread
From: Tim Goodwin @ 2000-01-04 16:43 UTC (permalink / raw)
  To: rc

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.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
@ 2000-01-03 15:46 Bengt Kleberg
  0 siblings, 0 replies; 21+ messages in thread
From: Bengt Kleberg @ 2000-01-03 15:46 UTC (permalink / raw)
  To: rc

Greetings,

After a (too long) delay I offer my comments to the rc-2.0 wish-list.
Points where I have no comment are just left out.

> 2. Compile-time limit on `;' separated commands in a line.

Good idea, it would be nice to remove built-in limits, and just leave te hard ones (RAM/swap space).

> 4. `shift' only works on `$*'.

Yes, please add this to the documentation. I needed it a few days ago (last millenium :-), and could
not invent it.

> 8 & 9, 12. Strange handling of parentheses.

Since my misunderstanding of while () {} probably started this thread I would like to add that I now
understand that syntax errors from
while (()) {}
is a feature and not a bug. However, it is confusing and should merit a comment in the documentation
of while/if/for

> 10. `$PATH' versus `$path'.

Please let $path inherit from $PATH, and also assigments to $path be reflected back to $PATH. I would much prefer to
think of them as always having the same value.

> 11. `.' should search `$path'.

Actually, I do not think so. I think it should not.

> 16. Make `*' match files beginning with `.'

Please do not.

> 17. Improved error reporting

Yes. A error report like
script-name:line-number 'error'
would be very useful.

> 19. Discard autoconf and automake.

Yes please. If this is 'a waste of time' for skilled programmers, consider using my time (it can be wasted upon such activities :-)

\x1f> 20. ~ expansion.

If absolutly neccessary, please make it a compile time option.

> 21. Add a command line flag that turns off free carets.

If I remember correctly this is a compile time option already. That is surely enough.

> 23. Dynamically load readline only when rc

Please do not. How about suggesting 2 rc shells in the documentation instead? One for scripts, and one for interactive use.
The latter with readline, the former without.

> 25. Gert-Jan Vons complains that using `=' in a command's arguments

It is ok as it is. I have gotten used to it.

> 26. Better testing.

Very good idea. Any thing in particular you want a test for?

> 27. Smaller, faster, cheaper.

Make this #1.


And finally, for my personal enjoyment: How about re-introducing

if not {}

as an alternative to

} else { }

I have 1 need for this, and I really think it would be nice to have both possiblities.


Best Wishes, Bengt
===============================================================
Everything aforementioned should be regarded as totally private
opinions, and nothing else. bengt@softwell.se
``His great strength is that he is uncompromising. It would make
him physically ill to think of programming in C++.''


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
  2000-01-07  3:45 ` Decklin Foster
@ 2000-01-01  4:20   ` Paul Haahr
  2000-01-15  8:58     ` Steve Kilbane
  0 siblings, 1 reply; 21+ messages in thread
From: Paul Haahr @ 2000-01-01  4:20 UTC (permalink / raw)
  To: Decklin Foster; +Cc: rc

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


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
  2000-01-12 21:34 Chet Ramey
@ 2000-01-01  2:55 ` Paul Haahr
  0 siblings, 0 replies; 21+ messages in thread
From: Paul Haahr @ 2000-01-01  2:55 UTC (permalink / raw)
  To: Chet Ramey; +Cc: rc

Chet Ramey wrote, quoting me
> > Interesting.  The docs for Plan 9 rc indicate that that's true, going
> > back to the version in the printed 10th edition manuals.  As do sh and
> > its descendents, though not the csh family.  According to Chet Ramey,
> > Posix mandates path searching for ``.'' in csh.
> 
> I assume you mean `sh' here.  POSIX.2, section 3.14.4.

Yes.  Sorry for any confusion.

--p


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
  2000-01-04 16:43   ` Tim Goodwin
@ 1999-12-31 23:26     ` Paul Haahr
  0 siblings, 0 replies; 21+ messages in thread
From: Paul Haahr @ 1999-12-31 23:26 UTC (permalink / raw)
  To: Tim Goodwin; +Cc: rc

Tim Goodwin wrote, replying to me, replying to him:

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

Great.

> >                                                  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? :-)

I guess I've been bitten so rarely by the restriction that it doesn't
bother me.  Much more troublesome as a practical matter, IMNHO, is the
restriction about not putting \0 in es strings, but that's much more
problematic to ``fix.''


> 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 it's just a bug in footobar.c:Tconv(), where the current code is
a little too pessimistic about when to insert parentheses.  See the case
which handles nCount, nFlat, and nVar.  The test which sets lp and rp
(using an audacious comma expression) should probably also look at the
contents of the string to see if it's got ``interesting'' characters.


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

Agreed.  Es avoids exporting $path and $home for that reason.


> > > 11. `.' should search `$path'.  This will be fixed.
> > Why?
> Every other shell does, including (I'm told) the Plan 9 rc.

Interesting.  The docs for Plan 9 rc indicate that that's true, going
back to the version in the printed 10th edition manuals.  As do sh and
its descendents, though not the csh family.  According to Chet Ramey,
Posix mandates path searching for ``.'' in csh.

But Byron's rc never has, and I don't think it should.  Byron put it
better than I could in a note to this list from 1993:

  From: byron@netapp.com (Byron Rakitzis)
  To: davidf@golem.waterloo.on.ca
  Cc: rc@hawkwind.utcs.toronto.edu
  Subject: Re: rc 1.5
  Date: 	Fri, 16 Apr 1993 18:21:39 -0400

  >Will 1.5 be brought into line with the Plan 9 man page?

  That's a good question. I'm hoping to freeze rc. I also don't feel
  the need to bring rc "into line" with anything else. So offhand I
  would say no. The flag command is present in plan9 rc for a very
  specific reason (/lib/rcmain). And I don't want dot to search
  my path. What if I do:

	  ; cat >test <<EOF
	  garbage
	  EOF
	  ; . test

  and "." is at the end of my path? Does this mean I run /bin/test
  as rc input? (THIS IS WHAT /bin/sh ACTUALLY DOES!!)

  No thank you.


> > > 13. Add the `flag' builtin ...
> > Why?
> [...]  The main reason is to make point 14 work, though.
> 
> > > 14. Add a command line flag that means "don't export any variables".
> > [...]
> 
> 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?

I would strongly suggest you leave this on the back burner (and perhaps
remove the comment from the man page) until it becomes a pressing issue
for real applications.


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

Except that it adds at least one more #ifdef option, which is a much
higher configuration and complexity increase than the utility of the
feature merits.

(I've come to believe that conditional compilation options are almost
always wrong.)


> >           Adding a ``rc:'' prefix seems a mistake to me.
> 
> Can you learn to live with it?

(Me?  I don't actually use rc anymore.  As much as I use a shell, I use
es, but I probably use complex shell commands once a day at most.  But I
continue to think of rc as one of the most nearly perfect programs I see,
so my advice about it will always be radically conservative.)

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

I guess I work on enough different problems from you that this hasn't
hit me.  The quotes do help in the error message, I think, and are
vastly preferable to the ``:'' sh and es use.  The rc prefix doesn't
add anything, but that's just my opinion.  (I guess I don't want the
shell to be drawing attention to itself.)

Much more useful, I think, as an addition to error messages would be
printing the program which actually died with a signal in a pipeline.
For example, in:

  ; ls | sleep 1000 | wc
        0       0       0
  illegal instruction
  ;

it could have been helpful to know that it was sleep that got killed.

--p


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
  1999-12-19 11:06 ` Steve Kilbane
@ 1999-12-22  0:00   ` Christopher Vance
  0 siblings, 0 replies; 21+ messages in thread
From: Christopher Vance @ 1999-12-22  0:00 UTC (permalink / raw)
  To: Steve Kilbane; +Cc: rc

On Sun, Dec 19, 1999 at 06:06:54AM -0500, Steve Kilbane wrote:
: I'm not familiar with readline and its variants, having never explicitly
: gone out looking for it. Does it provide anything other than history
: recall and editing? If not, $history is enough to provide 99% of that
: functionality via an external program.

I've always compiled rc with editline - it's much smaller than readline.
I do use recall and editting frequently.

The only hassle I've had is that interposing editline has occasionally
tripped up the trip tests, and I've had to convince myself that rc was
still okay...

-- 
Christopher Vance


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
  1999-12-16 12:43 Smarasderagd
@ 1999-12-19 11:06 ` Steve Kilbane
  1999-12-22  0:00   ` Christopher Vance
  0 siblings, 1 reply; 21+ messages in thread
From: Steve Kilbane @ 1999-12-19 11:06 UTC (permalink / raw)
  To: rc

When Tim mentioned "rc 2", I have to admit I was expecting something along
the lines of "same functionality, 'better' internals". The amount and
size of some of the changes being discussed is scary. ( different syntax,
different variable handling, different execution semantics, and different
input behaviour, and bigger, but otherwise business as usual ). And as
Paul/Byron said, if you want some of this, go use es.

The only one that makes sense to me is the error messages. I'd favour
"rc:" on the command line, and "script-name:" for scripts. If you were
going to always include "rc:", I'd want a space after it, so that it didn't
confuse wily with "rc:script:nn".

I'm not familiar with readline and its variants, having never explicitly
gone out looking for it. Does it provide anything other than history
recall and editing? If not, $history is enough to provide 99% of that
functionality via an external program.

steve




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
@ 1999-12-16 16:40 Chet Ramey
  0 siblings, 0 replies; 21+ messages in thread
From: Chet Ramey @ 1999-12-16 16:40 UTC (permalink / raw)
  To: byron; +Cc: rc, tjg, chet

> > 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.
> 
> I don't even know what to say about this. The mind boggles. The idea that
> the readline library is so cumbersome that it needs to be dynamically
> loaded really weirds me out. Is it that huge now? Processors have improved
> by a couple orders of magnitude since I wrote rc! What if a talented
> programmer spent a month doing a readline replacement?  Could he make
> it weigh in at 10% of the size of GNU readline? 5%?  1%?

It's not *that* cumbersome.

What about dynamic linking and shared libraries?  Maybe I'm missing
something here, but wouldn't simply linking rc against an
already-installed readline library, if one exists, result in 90% of
the benefits of rolling your own dynamic linking stuff without the
pain?

Bash has code in configure (and an option to select it) to figure out
whether or not to link against a system version of libreadline rather
than the version that comes in the bash distribution.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
@ 1999-12-16 12:43 Smarasderagd
  1999-12-19 11:06 ` Steve Kilbane
  0 siblings, 1 reply; 21+ messages in thread
From: Smarasderagd @ 1999-12-16 12:43 UTC (permalink / raw)
  To: rc, tjg

Tim Goodwin <tjg@star.le.ac.uk> writes:
>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".

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

I prefer the latter option for both of these, given the simplicity of the
workarounds and the lapse of time since the last argument about it.

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

Ditto previous objections.  Any sh/perl/etc. script that thinks it only
needs to update PATH/HOME and happens to run an rc script would break.

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

I'd be reluctant to possibly break scripts that assume that they can
source a file from the current directory even if "." isn't in $path.

>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 agree with Byron; the current behaviour is the correct consequence of
the syntax, not a bug.

>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.)
>
>     http://www.star.le.ac.uk/~tjg/rc/misc/td.html

Since, with the possible exception of -x, there aren't any flags you'd
want to turn on and off during the execution of a script, I don't know
if there's any point to this.

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

I once ran into a problem with a slide-show script which blew up
because the shell variable holding the list of images to display took
the environment past Linux's size limit for execve() and friends.
I fixed the problem pretty simply, and haven't run into it again,
but I can imagine situations where it isn't so easily avoided and the
limitation is more frustrating.

It's not entirely clear what it means to 'not export' a variable, though.
Do we make it available only to the current invocation of the shell, and
not to explicit subshells invoked via '@{ ... }', but still provide it
to other subshells, such as in pipelines?  I think it'd be worse to create
a peculiar class of variables with a list of exceptions which make sense
only if you know about the implementation.

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

I'm not sure how useful this is, given that many utilities and the C/C++
library generally make sweeping assumptions that break badly when you
try to make them interact through anything other than a (pseudo-)tty.
The only application I can think of offhand is testing network software.

I'd favour providing some helper program(s) for setting up bidirectionally
connected programs and/or pipelines.

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

I tend to think prefixing errors with 'rc:' in interactive sessions is
ugly, though it might have saved me some confusion in the past (I was
trying to run "host" on a system where it wasn't installed, and began
to think that DNS was down because I got "host not found" on every query...)

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

As a 9term user, I mostly want to thrash out the old 'history' utility
so that it compiles reliabily with optimization and doesn't sometimes
skip lines with a lot of hyphens in them.

>22. Add a `sigeof' function, which is invoked when rc sees EOF on
>standard input when it's a terminal device.  If sigeof returns 1, rc
>attempts to continue reading from standard input.
>
>    fn sigeof { echo 'Type `exit'' to leave the shell' >[1=2]; return 1 }
>
>(Suggestion due to Mark K Gardner.)

I desired this briefly when I wanted to prevent accidentally logging
out my console window, but I found that

while () {. -i /dev/tty; echo NO NO NO NO}

did the job for me.  You can insert the continue-or-exit logic of your
choice in place of the "NO" bit.

>28. That's all for now, folks!


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
@ 1999-12-15 16:32 Russ Cox
  0 siblings, 0 replies; 21+ messages in thread
From: Russ Cox @ 1999-12-15 16:32 UTC (permalink / raw)
  To: rc

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

What operating system doesn't demand-load the binaries anyway?
If you're not using the readline code, (the large majority of) it won't
be resident in memory.

And furthermore surely your OS is sharing text pages, so as long
as there is one rc binary running on a terminal, you've already got
it loaded and there's no penalty for running more or for running
scripts.

As Byron said, the mind boggles.

Russ



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
  1999-12-10 16:55 Tim Goodwin
  1999-12-13 18:54 ` Paul Haahr
@ 1999-12-15  0:17 ` Chris Siebenmann
  2000-01-07  3:45 ` Decklin Foster
  2 siblings, 0 replies; 21+ messages in thread
From: Chris Siebenmann @ 1999-12-15  0:17 UTC (permalink / raw)
  To: rc

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

 I disagree for the already stated reasons. $PATH is standard on Unix;
when rc starts, if $PATH and $path disagree, something has fiddled with
$PATH and expects the fiddling to be respected. Similarly for $HOME
and $home.

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

 If Plan 9 rc doesn't, I don't think we should either.

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

 This might be a good idea in a new shell, or for rc on a new system
(without the cultural history of dotfiles).

 I think it is a really bad idea for an existing shell on an existing
system, for all the obvious reasons. I would never run a version of
rc that behaved this way here.

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

 My personal opinion is that rc should report errors in a shell script
marked both with rc's name and with the script's name (so that it is
obvious that it is a syntax error in the script, and not an error
message being emitted by the script).

 I think rc should retain its current way of reporting the exit status
of commands run directly from an interactive session.

 Whether rc should print 'rc: ' in front of syntax errors during
interactive sessions seems like a religious issue. In the name of
minimalism, I'd vote no.

	- cks


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
@ 1999-12-14  9:44 Byron Rakitzis
  0 siblings, 0 replies; 21+ messages in thread
From: Byron Rakitzis @ 1999-12-14  9:44 UTC (permalink / raw)
  To: rc, tjg

A couple of comments, not exhaustive:

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

They are not syntax errors -- 

	; while ((~ 1 1) && (~ 2 2)) {}
	~ not found

Parentheses introduce a word list -- a command list is introduced
with {}. Thus:

	; while ({! 1 1} && {! 2 2}) {}
	1 not found
	2 not found
	1 not found
	2 not found
	1 not found
	2 not found

Maybe I don't understand the nature of the complaint.

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

I'm really unsure about the justification for this. This breaks
compatability with so many versions of Unix that it really makes me
wonder what the point is. Just because plan 9 doesn't have dotfiles
doesn't necessarily mean we want to foist this on Unix users of rc.

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

I don't even know what to say about this. The mind boggles. The idea that
the readline library is so cumbersome that it needs to be dynamically
loaded really weirds me out. Is it that huge now? Processors have improved
by a couple orders of magnitude since I wrote rc! What if a talented
programmer spent a month doing a readline replacement?  Could he make
it weigh in at 10% of the size of GNU readline? 5%?  1%?

Sorry, it's late here and I'm babbling.

Byron.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
  1999-12-10 16:55 Tim Goodwin
@ 1999-12-13 18:54 ` Paul Haahr
  2000-01-04 16:43   ` Tim Goodwin
  1999-12-15  0:17 ` Chris Siebenmann
  2000-01-07  3:45 ` Decklin Foster
  2 siblings, 1 reply; 21+ messages in thread
From: Paul Haahr @ 1999-12-13 18:54 UTC (permalink / raw)
  To: Tim Goodwin; +Cc: rc

> 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


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: rc futures
@ 1999-12-13 12:55 Elliott Hughes
  0 siblings, 0 replies; 21+ messages in thread
From: Elliott Hughes @ 1999-12-13 12:55 UTC (permalink / raw)
  To: rc


re: shift, i disagree with the idea of an "anyshift" function, given
that it's so easy to make an extended shift backwards-compatible.
see the patch i either posted here or mailed to tim earlier this year.
i seem to recall that my builtin was shorter or the same length as
the current one. i think it's silly to hack around something that we
can so easily and cleanly fix properly.

re: dot files
i agree that special treatment of dot files is mistake.

re: improved error reporting
this would be a great benefit. my own copy of rc is hacked to sort
of do this, but it's not quite right and you're as well off doing it
again from scratch (i know i would). rc should prefix its errors "rc: ".

re: = in args
this is a real pain, but i take your word for it that changing the
interpretation of = past the first non-assignment in a line is hard.

	-e

-- 
"As the Chinese say, 1001 words is worth more than a picture."
	-- John McCarthy


^ permalink raw reply	[flat|nested] 21+ messages in thread

* rc futures
@ 1999-12-10 16:55 Tim Goodwin
  1999-12-13 18:54 ` Paul Haahr
                   ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Tim Goodwin @ 1999-12-10 16:55 UTC (permalink / raw)
  To: rc

It's good to see some discussion on the list again.

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.

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

I have a number of ideas for changes, which are listed below.  The first
section comments on the items listed in the BUGS section of the man
page.  The second section lists other items that I have a reasonably
clear idea of how to tackle.  The third section is more contentious or
nebulous ideas.

All comments are welcome.

Tim.


Documented bugs

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

2. Compile-time limit on `;' separated commands in a line.  I think it
is possible to fix this, although it may not be worth the effort.

3. Problems with FIFOs.  Has anybody ever actually seen these problems?
If there's a repeatable test case, I can probably fix it.

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

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

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.

8 & 9. Strange handling of parentheses.  I think this can be fixed with
some tweaks to the grammar, and probably is worth it.

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

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

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


Other likely changes

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

     http://www.star.le.ac.uk/~tjg/rc/misc/td.html

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

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

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

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.

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

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.


Other possible changes.

20. ~ expansion.

21. Add a command line flag that turns off free carets.

22. Add a `sigeof' function, which is invoked when rc sees EOF on
standard input when it's a terminal device.  If sigeof returns 1, rc
attempts to continue reading from standard input.

    fn sigeof { echo 'Type `exit'' to leave the shell' >[1=2]; return 1 }

(Suggestion due to Mark K Gardner.)

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.

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

    ; # ifs has its default value
    ; x = `{ echo 'this  is a    test' }
    ; whatis x
    x=(this is a test)

    ; ifs=,
    ; x = `{ echo this,is,,a,test }
    ; whatis x
    x=(this is a 'test
    ')

But in the second example, we'd really like to see this.

    x=(this is '' a test)

One suggestion (due to Donn Cave) is to make rc use its existing
rules when `$ifs' contains multiple characters, and to use "repeated
separators imply null values" when `$ifs' contains only a single
character.  (There is a separate question of whether newlines should be
trimmed in this case.)

I see the problem, but I'm not keen on this solution.

25. Gert-Jan Vons complains that using `=' in a command's arguments is a
syntax error.  I find this frustrating, too, but I can't think of a cure
that isn't worse than the disease.

26. Better testing.  It bothers me that I have added 22 "Bug:" entries
to the ChangeLog, but only 4 regression tests to trip.rc.  To some
extent, this is inevitable.  It simply isn't possible for trip.rc---or
any test infrastructure that can work wherever rc does---to create a
file which the user is entitled to execute only because of a secondary
group membership, or to construct a file which can be open()ed for
reading, but not read().  But I think we should do better.  A second
problem with trip.rc is that it assumes certain Unixisms, so it doesn't
work at all under CygWin, for instance.

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.  I think the new Makefile
maker mentioned in 19 will achieve both these goals.

28. That's all for now, folks!


^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2000-01-18  4:52 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-14 12:16 rc futures Bengt Kleberg
  -- strict thread matches above, loose matches on Subject: below --
2000-01-14 12:20 Bengt Kleberg
2000-01-12 21:34 Chet Ramey
2000-01-01  2:55 ` Paul Haahr
2000-01-12 14:22 Bengt Kleberg
2000-01-03 15:46 Bengt Kleberg
1999-12-16 16:40 Chet Ramey
1999-12-16 12:43 Smarasderagd
1999-12-19 11:06 ` Steve Kilbane
1999-12-22  0:00   ` Christopher Vance
1999-12-15 16:32 Russ Cox
1999-12-14  9:44 Byron Rakitzis
1999-12-13 12:55 Elliott Hughes
1999-12-10 16:55 Tim Goodwin
1999-12-13 18:54 ` Paul Haahr
2000-01-04 16:43   ` Tim Goodwin
1999-12-31 23:26     ` Paul Haahr
1999-12-15  0:17 ` Chris Siebenmann
2000-01-07  3:45 ` Decklin Foster
2000-01-01  4:20   ` Paul Haahr
2000-01-15  8:58     ` Steve Kilbane

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).