Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!transfer!lectroid!jjmhome!smds!rh From: rh@smds.UUCP (Richard Harter) Newsgroups: comp.unix.shell Subject: Re: separate the command language and interactive she Summary: The great divide Message-ID: <424@smds.UUCP> Date: 28 Apr 91 06:02:23 GMT References: <2509@optima.cs.arizona.edu> Organization: SMDS Inc., Concord, MA Lines: 61 In article <2509@optima.cs.arizona.edu>, gudeman@cs.arizona.edu (David Gudeman) writes: ... A number of comments on my comment which I am going to draw on but now quote directly. First of all, some terms: > Just to clarify my terms: I would call sh a command language and csh a > combination of command language and interactive shell... 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. David's dividing line is a little loose but the general notion is that the interactive features belong in the ish and command execution belongs in the clang. He remarks that there is assumption of a line oriented interface involved here. On this matter it seems reasonable that (a) the clang is line oriented and that (b) it can either operate standalone or take its input from the ish. There is an implication here that the clang is a servant of the ish; i.e. an ish can select a clang but a clang cannot select an ish. (Except as a subprocess.) Howabout stdout? One gets the feeling that stdout should go through the ish, i.e. all output of the clang and its subprocesses are piped back to the ish. This all implies (I think) that the ish and the clang are separate processes with the clang being started by the ish. Since the clang is a child that should resolve environment variable issues shouldn't it? Following this line we have three units 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. The clang: It executes as a standalone command processor. Its input comes from stdin and goes to stdout and stderr; what happens to them is none of its business. 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. Oddly enough the ish process never goes anywhere; i.e. cd and pwd are executed by the clang. Another point is that the ish will need some special commands to set its own environment variables and to do clang selection. 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. All of this implies in turn that the clang must also have its own encapsulated interface. -- 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.