yes. there are a couple (okay, three) problems to address here. byron and
paul haahr
addressed some of the problems with a shell called "es" years ago, even though
they
didn't have dynamic modules.
1. what interface do external modules get to see? perhaps masquerading as
a shell function would be good enough.
2. what hooks are provided by the shell. the "es" shell provided a hook
for darn near every language construct there was. for example, it was possible
to redefine globbing, piping, the if statement, etc.
i thought the result was effective, but somewhat like pounding a nail with
a jackhammer. (traditional shell syntax was first converted from
a | b
to es's perferred syntax
%pipe {a} 0 1 {b}
then bound as
$&pipe {a} {b},
assuming one hadn't redefined %pipe.)
3. shell syntax vs. command syntax. the shell's syntax often gets in the way
of command syntax. mike hartel wrote up some stuff about this years ago.
basically, it's a pain that the shell and, say, grep, want to use the same
characters.
i can't just type
; grep ^fn *.[ch]
i must type
; grep '^fn' *.[ch]
instead. this would get very difficult if one added awk-like functions to the
shell.
es did this: anything passed to a function inside curly braces was passed
verbatim.
thus "if" in es looks like a normal es function call:
; if {condition1} {body1} {condition2} {body2}
a trivial grep module could make
; grep {^fn} *.[ch]
acceptable syntax.
- erik
On Wed Apr 19 14:35:12 CDT 2006, [EMAIL PROTECTED] wrote:
>
> Personally, my dream has always been to make all of the applications
> which rely heavily on console input-output to be dynamically loaded
> on top of each other, so that when I do something like:
>
> $ bash
> <long session with bash, with lots of useful stuff in history and such>
> $ gdb
>
> I don't leave shell (and lose all of the context) but I rather have
> my shell augmented with gdb commands. Sort of like Tcl works with
> external modules.
>
> Have anybody thought about anything likes this ?
>
> Thanks,
> Roman.
