separate the command language and interactive shell

Thu May 9 02:24:48 AEST 1991

|In article  <-#8Gd-e*1 at cs.psu.edu> Felix Lee writes without
|understanding anything that he is replying to:

Please try and keep this civil.  I think that Felix understood what he
was replying to.

No you can't.  You don't know what the characters mean, and every
clang might be different.  ~john means john's home to [ck]sh, nothing
special to sh, and ``not john'' to a debugger.  How do you propose to
complete it in ish?

|]How about completing filenames with variables embedded: "$HOME/$a/a".
|
|This is a non-problem.  The ish gets the value of the environment
|variable and completes however the ish-writer thought it should be
|done.

It might not be an environment variable.  How can the ish writer know
what the clang writer thought a file should be?

I'm running a cooperating sh clone under ish:

$ foo=bar
$ ls -l ~/${foo}bar/pr<ESC><ESC>

How can ish complete that?  Now change "sh" above to "ksh" and try
again.  They have to complete differently, how can ish know that?

How can ish complete:

$ ls -l ${foo%a*}ogus.<ESC><ESC>

And what about:

$ IFS=': '
$ ls:-l:$foo/prog<ESC><ESC>

I don't want my clang to be restricted to your ish syntax.  Keep the
ish simple, let it do what it reasonably can (history, line editing)
and let the clang do what it does (interpret the command line).

|]How about glob completion: expand things like "*" and "f*".
|
|If the ish writer wants to expand wildcards, the ish can do so.

Again, what wild cards?  Csh-like, sh-like, ksh-like?  I don't want
the ish to force this on all my clangs.

|]A more serious problem: the shell isn't the only thing that
|]wants/needs completion.  gdb, for example, wants to do completion.
|
|That was one of the considerations that lead to my suggestion in the
|first place.  Write a command line description for gdb just like for
|the clang.

And another for sh, ksh, csh, rc, ed, sdb, dbx, and roll all these
into ish?  Leave the command line parsing in the command, where it's
already being done.

|]Teaching the front-end about all this gets ugly.
|
|All of this is part of the front end, there is no "teaching" about it.

Sure there is.  You just said ``Write a ... description for gdb''.
That's teaching ish about gdb syntax, whether at compile time or run
time (I'm not sure which you're advocating).  Every time you expand ish
this way, I'll add a new clang with a conflicting syntax.

|]The simplest way to handle completion is to have a communication
|]channel between the front-end and the current interactive process.
|
|It might make life a little easier for the ish writer, but it makes
|life harder for the clang writer.  Since completion is an ish feature,
|the clang writer should not have to worry about it.

I disagree.  Completion is context-dependent on how the clang is going
to interpret the command-line, so it belongs with the clang.  And it
doesn't really make the clang harder.  In both your mechanism, and the
one Felix and I seem to like, the clang must do completion.  In yours,
you make ish parse the line and send a succinct completion request to
the clang, which does the completion.  I make the clang parse the line
_because it has to be able to parse lines anyway_ and then do the
completion.

|](Which immediately has two problems in Unix: What's the "current
|]interactive process"?  How do I talk to it?  (So how do we fix Unix?))
|
|My supposedly more complex scheme doesn't have either problem.

Actually it still has the problem of hiding the communication with the
clang if you want to do that.

Your scheme is complex in that it requires a command line parser be
built into ish, and further, that it either be able to parse the
conflicting syntax of every clang it is to run, or the clang user
loses ish-functionality (eg. completion) on things that ish cannot
parse.