Re: rc as an embedable language

Re: rc as an embedable language

[Arnold D. Robbins]

> Date: Sat, 24 Aug 1991 01:19:13 -0500
> From: emory!redvax.uucp!hugh ("D. Hugh Redelmeier")
> Subject: rc as an embedable language
> 
> I like interactive visual editing of history in an interactive
> shell.  There.  I have admitted it.  I even like filename completion!

Me too!

> I don't like fat and ugly interactive history support in my scripting
> language.

Me too!

> How can these be resolved?  Some ways:

A fourth way:

 - Put all the interactive candy into readline.

This is what Byron chose, and is actually reasonable.  At my urging,
Chet Ramey of bash fame has been beating on vi mode in readline.  I sent him
diffs so that when a person does a file name completion on

	; echo ~arnold/a*

readline turns it into

	; echo /u/arnold/a1 /u/arnold/a2

so that rc never sees the ~ stuff (diffs work for vi and emacs mode).
I almost had it working so that a new key did plain tilde expansion.
This is a compromise --- the user has to type something to do the expansion,
but the hair all stays in readline.  For scripts, a simple function
would do:

	fn homedir { for (i) awk -F: '$1 == '$i' { print $6 }' }

	echo `{homedir arnold joe jane}

> I would like to suggest that a version of the first technique could
> have some advantages.  If rc were implemented as a (shared?)
> library, like TCL, it would be easy to create two variants of the
> same shell.  One could have the interactive candy; one could be a
> lean and elegant scripting shell.  Much of the two shells would be
> shared.
> 
> This library would also be attractive as an embeddable language,
> much like Scheme and TCL.

This has some real possiblities.

David Korn once told me about some work people did making ksh an embeddable
language, and hooking it into their X-Windows application.  They could write
a ksh script for when buttons were pushed etc.  I think rc is more attractive
for this sort of thing, since it's a lot smaller.

The concept is by no means far-fetched.

Arnold

Re: rc as an embedable language

[Chris Siebenmann]

 ash (a sh-like shell I used before rc) solved the problem of line editing
and file completion in an interestingly novel way, although it isn't fully
general: there was a sepperate file matching program, and when the editing
frontend program wanted to do file completion, it saved away the current line
and sent the underlying shell a 'fmatch partial-filename' command. There was
an escape-based sequence that fmatch and the front end used to communicate,
as well as a special set of escape sequences that could be used to hide
the actual fmatch command execution itself (if the shell knew about it).

 This worked pretty well, although it does have obvious problems; it doesn't
work in the middle of complex commands being entered on sepperate lines, and
it counts on the underlying shell being more or less sensible -- it would
break if you couldn't execute the command line.

	- cks

rc as an embedable language

["D. Hugh Redelmeier"]

I like interactive visual editing of history in an interactive
shell.  There.  I have admitted it.  I even like filename completion!

I don't like fat and ugly interactive history support in my scripting
language.

How can these be resolved?  Some ways:

- Separate interactive and scripting shells.
  I find that this works pretty well.  This has been my preferred
  technique for the last four years.  It seems like a shame to have
  two independent shells (to learn, implement, or maintain).

- Separate history editor program and shell.
  This breaks down when it comes to filename completion:
  whatever does the completion must know the shell's current
  directory (not to mention that the regexp stuff needs to be
  duplicated.)

- Put it all in the shell: it won't get in your way anyway.
  My recent use of ksh supports this, but it bothers me.
  Even though I am the designer of the editing keystrokes
  used in - and --, I find them very awkward compared to ksh's
  visual intraline editing.

I would like to suggest that a version of the first technique could
have some advantages.  If rc were implemented as a (shared?)
library, like TCL, it would be easy to create two variants of the
same shell.  One could have the interactive candy; one could be a
lean and elegant scripting shell.  Much of the two shells would be
shared.

This library would also be attractive as an embeddable language,
much like Scheme and TCL.

Of course, such a change is too much to expect Byron to do, and I am
not volunteering.  I just mention this to justify my taste for
interactive candy.

Hugh Redelmeier
{utcsri, yunexus, uunet!attcan, utzoo, scocan}!redvax!hugh
When all else fails: hugh@csri.toronto.edu
+1 416 482-8253