gudeman@cs.arizona.edu (David Gudeman) (04/30/91)
In article <424@smds.UUCP> Richard Harter writes:
]
]David introduces the terms ish for interactive shell and clang for the
]command language. He wasn't thinking in terms of anything radically
]different from sh as the clang; in my view one should keep this possibility
]carefully in mind from the beginning.
As I said before, I think this is a good idea, but you have to keep in
mind the conservatism of many users. It is easier to introduce new
ideas a little bit at a time instead of all at once. There are
already a large number of programming languages with line-oriented
interaction (Lisp and Prolog are probably the most well known). Given
independent ish and clang, many people might find it convenient to use
an ish with one of these languages as their normal shell.
]The ish: It talks to the terminal and, as far as interactive action
]goes, can be whatever you like. It doesn't execute OS commands; its
]command syntax or window widgets or whatever are its responsibility.
]All terminal IO ends up going through it.
Yes. The ish on a tty is like a window manager on a workstation --
who knows, it may even provide windows. On a workstation the ish
would probably be relegated to a single window.
]...The interface: It is encapsulated in the ish. It starts the clang
]process and handles passing I/O back and forth. David suggests using
]control characters for communication of special commands. Offhand I
]don't like this kind of notion; it's probably better not to build in
]assumptions like that. Wouldn't it be better to have a separate
]communications path.
Yes, I guess you are right. How would you go about implementing that
sort of thing giving the following possible combinations? (1) Running
an ish and clang together that both understand the communication. (2)
runing an ish that understands the communication with a clang that
doesn't. (3) Running a clang that understands the communication on a
bare tty (no ish). (4) Running an ish and clang together that both
understand the communication, where the clang invokes another program
that may or may not understand the communication (neither the ish nor
the clang can know this).
]Also one has to take care of interrupts, i.e. if
]one issues an interrupt to the ish it has to trap it and pass it to
]the clang with the requirement that (a) if the clang is executing
]it accept the interrupt or (b) if it is executing a subprocess the
]interrupt be passed to the subprocess.
I assume you mean that the ish has to pass keyboard-initiated
interrupts on to the currently running child right? As a note, the
currently running child may not be the clang, it may be any program
that doesn't take over the terminal. I think the effect of various
keys should be up to the ish design. Most ishes would probably use
raw mode and just translate certain keys as interupt initiators.
]All of this implies in turn that the clang must also have its own
]encapsulated interface.
In don't understand this comment. I don't think the clang needs
anything more than to read lines from stdin and stdout and write them
to stdout -- except for communication with the ish. What sorts of
information might this include? And could that information be
specified somewhere besides in the actual clang? What about a special
start-up file that tells the necessary information about the clang (or
any other other line-based program).
--
David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudemangudeman@cs.arizona.edu (David Gudeman) (05/07/91)
In article <-#8Gd-e*1@cs.psu.edu> Felix Lee writes without
understanding anything that he is replying to:
]> <command-line> ::= <command> <arg>* | "set" <var> = <arg>
]> <arg> ::= "-"<char>* | "$"<var> | <file>
]> path-complete <command> with "echo $path"
]> path-complete <file> with "pwd"
]> list-complete <var> with "variable-completion %s"
]
]Let's see. The syntax is naive: it doesn't do quoting of any sort, so
]you can't do file completion on files with special characters in it.
I can make the syntax as complex as needed and do file completion with
any characters.
]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.
]How about history completion: expand things like "!$" and "!vi".
History is entirely handled in the ish. If the ish writer thinks
there should be history completion there can be.
]How about glob completion: expand things like "*" and "f*".
If the ish writer wants to expand wildcards, the ish can do so.
]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.
]Teaching the front-end about all this gets ugly.
All of this is part of the front end, there is no "teaching" about it.
]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.
](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.
--
David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudemanallbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/11/91)
As quoted from <2832@optima.cs.arizona.edu> by gudeman@cs.arizona.edu (David Gudeman): +--------------- | ]How about glob completion: expand things like "*" and "f*". | | If the ish writer wants to expand wildcards, the ish can do so. | | ]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 how do you tell ish to complete a variable name for gdb? This leads directly into: +--------------- | ]Teaching the front-end about all this gets ugly. | | All of this is part of the front end, there is no "teaching" about it. | | ]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. +--------------- ...but if the possible completion values are generated internally to the clang, there had *better* be a way to tell the ish how to complete them, or your completion scheme is going to fall apart. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH