rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: Tim Goodwin <tjg@star.le.ac.uk>
To: rc@hawkwind.utcs.utoronto.ca
Subject: rc futures
Date: Fri, 10 Dec 1999 11:55:06 -0500	[thread overview]
Message-ID: <Fx4AAIAwUTjePAYA@ltsun0.star.le.ac.uk> (raw)

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!


             reply	other threads:[~1999-12-12  7:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-12-10 16:55 Tim Goodwin [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Fx4AAIAwUTjePAYA@ltsun0.star.le.ac.uk \
    --to=tjg@star.le.ac.uk \
    --cc=rc@hawkwind.utcs.utoronto.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).