rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* 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
* 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
* 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-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-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-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
@ 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-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
@ 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-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-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

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 --
1999-12-10 16:55 rc futures 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
1999-12-13 12:55 Elliott Hughes
1999-12-14  9:44 Byron Rakitzis
1999-12-15 16:32 Russ Cox
1999-12-16 12:43 Smarasderagd
1999-12-19 11:06 ` Steve Kilbane
1999-12-22  0:00   ` Christopher Vance
1999-12-16 16:40 Chet Ramey
2000-01-03 15:46 Bengt Kleberg
2000-01-12 14:22 Bengt Kleberg
2000-01-12 21:34 Chet Ramey
2000-01-01  2:55 ` Paul Haahr
2000-01-14 12:16 Bengt Kleberg
2000-01-14 12:20 Bengt Kleberg

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