rh@smds.UUCP (Richard Harter) (04/26/91)
I am cross posting this to comp.lang.misc. If you wish to follow up to one group only, please edit the newsgroups line. In article <585@lysator.liu.se>, bellman@lysator.liu.se (Thomas Bellman) writes: > gudeman@cs.arizona.edu (David Gudeman) writes: DG: Maybe I'm missing something, but it seems to me that many of the Unix DG: shells combine two seperable functions: the command language and the DG: interactive shell. Is there some advantage to this? It seems to me DG: that there would be several advantages to seperating them. DG: (1) users would have more options. They would not have to pick the DG: shell that gives them the best command-line editing even though they DG: don't like the control structure syntax. [...] DG: (2) the features of the interactive shell could be used for other DG: programs. [...] DG: (3) related to (2), programs that present virtual terminals (like DG: xterm and emacs) could have a complete window-editing environment DG: without having to load those functions for the shell as well. DG: (4) the command language program could be smaller, possibly giving DG: faster startup for system() calls. TB: I think this would be good. The proper way to do it, would be to have TB: a smarter cooked mode AND let the user load his own cooked mode TB: library. To do this in current Unices I think would be difficult. TB: The only problem is if you want some key interact specially with the TB: underlying program. E g in BASH, you can press ESC ctrl-e to expand TB: all variables, aliases and backquote expressions in the line, so you TB: can edit the result. I don't have any ideas for how to do this, but TB: it's something I would like to do. TB: Personally, I don't like the idea of having different historys for TB: different programs, since I often do something in one program, and TB: then want to use what I wrote there, in the shell. But that could TB: easily be remedied by switching to another cooked mode library. Actually I think this is an excellent idea; however there are some issues to be resolved. I am going to use Lakota as a reference point since it was designed with this kind of usage in mind; however other languages such as TCL, Python, and Icon are relevant. Lakota is an interpreted language implemented as a C callable library with a handful of entry points, e.g., (a) Create a pseudo-process (b) Activate (resume) a pseudo-process with input coming from (1) Standard input (2) A null terminated string passed to the pseudo-process (3) A script file (c) Attach C functions as commands/functions to the language. The other relevant features are (a) commands which are not recognized as Lakota commands are executed in a designated subshell, (b) the interpreter captures interactive history, and (c) access to stdin is encapsulated. Given these features it is trivial to write a simple shell based on Lakota and, in fact, this is a normal implementation. To implement David's interesting proposal in a useful form what one really needs is a solid protocol for the interface between the shell and the command language. Here are some of the issues that occur to me: (a) History recording Presumably the shell is responsible for history editing. Who has the responsibility for capturing history? If multiple programs (processes, pseudo-processes) are sharing the interpreter, can command history information be passed from one to another? (b) Command completion A popular feature of some shells is command and/or file completion. Does this extend to commands in the shell language? If so, how does the interpreter pass to the shell the list of commands to search? (This isn't hard, but one needs a spec.) (c) Processes and pseudo-processes A Lakota pseudo-process is implemented as part of the parent process. The issue here is whether the command language interpreter executes as part of the shell process or as a separate (cooperating process). (d) Environment variables Does the shell or the command interpreter have the responsibility for managing process environment variables? What are the rules? -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.