gudeman@cs.arizona.edu (David Gudeman) (04/21/91)
Maybe I'm missing something, but it seems to me that many of the Unix shells combine two seperable functions: the command language and the interactive shell. Is there some advantage to this? It seems to me that there would be several advantages to seperating them. First, by "command language" I mean the functionality of parsing the command lines and invoking programs. By "interactive shell" I mean command-line editing and history mechanisms. Filename globing and process control are probably best considered part of the command language (but I'm not sure about that). I can think of the following advantages to seperating these two functionalities: (1) users would have more options. They would not have to pick the shell that gives them the best command-line editing even though they don't like the control structure syntax. Of course you can partly get around that problem now by using different shells for interactive vs. script purposes, but that is not ideal. (2) the features of the interactive shell could be used for other programs. For example, the history mechanism could have different history lists for different prompts, and every program with a recognizable prompt could be used with the exact same history mechanism and command-line editing as the shell. And those other programs would not have to implement interactive functions (as many do). (3) related to (2), programs that present virtual terminals (like xterm and emacs) could have a complete window-editing environment without having to load those functions for the shell as well. (4) the command language program could be smaller, possibly giving faster startup for system() calls. -- David Gudeman gudeman@cs.arizona.edu noao!arizona!gudeman
byron@archone.tamu.edu (Byron Rakitzis) (04/21/91)
In article <2219@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes: >Maybe I'm missing something, but it seems to me that many of the Unix >shells combine two seperable functions: the command language and the >interactive shell. Is there some advantage to this? It seems to me >that there would be several advantages to seperating them. Yes, you are right. More later. >I can think of the following advantages to seperating these two >functionalities: >(1) users would have more options. >(2) the features of the interactive shell could be used for other >programs. >(3) related to (2), programs that present virtual terminals (like >xterm and emacs) could have a complete window-editing environment >without having to load those functions for the shell as well. >(4) the command language program could be smaller, possibly giving >faster startup for system() calls. These are all very good reasons, and let me note that I have been thinking about this for a while now. To this end, for the last year or so, I used sh with xterm as my preferred interface to Unix; xterm gave me a rudimentary command-line editing and history mechanism, whereas sh gave me the simple command language that I wanted. However, since then, I've been trying to improve this state of affairs. My first step was to write a shell. I used the plan 9 shell "rc" as a prototype, though I eventually plan to write a shell of my own design. This shell is more powerful than sh, yet manages to be more compact. It was also designed with a windowed environment in mind, so that for example, all "aliases" are kept in the environment so that new instances of the shell to not have to read the configuration file (.rcrc). Now, all that needs to be done is to write a better xterm. By this, I do not mean a cursor-addressible terminal emulator, rather an "editable terminal" in the style of mux. This et would understand enough control sequences in order to support more(1), but other than that it would be the moral equivalent of the shell window in emacs, with the difference that most editing is performed by the mouse. I think this would provide all the power one needs to interact with a shell. Any takers? :-) -- To reveal art and conceal the artist | Byron Rakitzis, Texas A&M. is art's aim. -- Oscar Wilde. | byron@archone.tamu.edu
bellman@lysator.liu.se (Thomas Bellman) (04/21/91)
gudeman@cs.arizona.edu (David Gudeman) writes: > Maybe I'm missing something, but it seems to me that many of the Unix > shells combine two seperable functions: the command language and the > interactive shell. Is there some advantage to this? It seems to me > that there would be several advantages to seperating them. > (1) users would have more options. They would not have to pick the > shell that gives them the best command-line editing even though they > don't like the control structure syntax. [...] > (2) the features of the interactive shell could be used for other > programs. [...] > (3) related to (2), programs that present virtual terminals (like > xterm and emacs) could have a complete window-editing environment > without having to load those functions for the shell as well. > (4) the command language program could be smaller, possibly giving > faster startup for system() calls. I think this would be good. The proper way to do it, would be to have a smarter cooked mode AND let the user load his own cooked mode library. To do this in current Unices I think would be difficult. The only problem is if you want some key interact specially with the underlying program. E g in BASH, you can press ESC ctrl-e to expand all variables, aliases and backquote expressions in the line, so you can edit the result. I don't have any ideas for how to do this, but it's something I would like to do. Personally, I don't like the idea of having different historys for different programs, since I often do something in one program, and then want to use what I wrote there, in the shell. But that could easily be remedied by switching to another cooked mode library. -- Thomas Bellman, Lysator Computer Club ! "Make Love - Nicht Wahr" Linkoping University, Sweden ! "Too much of a good thing is e-mail: Bellman@Lysator.LiU.Se ! WONDERFUL." -- Mae West
jmason@gpu.utcs.utoronto.ca (Jamie Mason) (04/23/91)
gudeman@cs.arizona.edu (David Gudeman) writes: | Maybe I'm missing something, but it seems to me that many of the Unix | shells combine two seperable functions: the command language and the | interactive shell. Is there some advantage to this? It seems to me | that there would be several advantages to seperating them. | (1) users would have more options. They would not have to pick the | shell that gives them the best command-line editing even though they | don't like the control structure syntax. [...] I use the csh for typing commands. I like it very much (even though some users of larger shells (eg tcsh, bash, etc...) would find it's history mechanism and the like rather primitive. I find the csh to be a nice interactive shell. But for scripts, it should be called the cs*HELL*. I used to use #!/bin/csh for my shell scripts. But there are problems. Csh comes up too slowly, even with -f. Csh sufferes major forms of brain damage for shell programming. For instance the 'undefined varible' b.s. that csh barfs up and crashes your scripts. Or the fact that quoted inline text must escape all the returns, even inside quotes, so an awk script embedded in a csh script must be written as awk '\ BEGIN {foo}\ /foo/ {bar}\ END {baz} ' There is so much csh brain damage not mentionned here that I finally learned my lesson and started programming in /bin/sh. Bourne shells may lack the nice C-like syntax for control structures, but there is one overriding advanatge to /bin/sh syntax: it is *CONSISTENT*. There is no silly brain damage, what works WORKS. /bin/sh treats whitespace consistenly (newline ~= space). It treats quoting consistently. And for all the (relatively) ugly syntax (what's the most natural way to end an if? fi is *REAL* natural, same with esac :-), the command language fits together in an intuitive way, without all the silly cshell warts. So I could not agree more -- separate the interactive shell from the command language. Most of us already have, anyways. In article <585@lysator.liu.se> bellman@lysator.liu.se (Thomas Bellman) writes: >I think this would be good. The proper way to do it, would be to have >a smarter cooked mode AND let the user load his own cooked mode >library. To do this in current Unices I think would be difficult. Oh. OUCH! Yeah, we will have Tcsh or BASH (!) type stuff in the cooked mode. TTY aliases. I can just see an IOCTL to do it! And linking your own cooked mode driver into the Kernel? I imagine it could come in with a STREAMS module Push. And users could load THEIR OWN CODE INTO THE KERNEL to do it! Ouch! Uuuggghhh! * K E R N E L B L O A T ! ! ! * Yes, I think it isa good idea, but I think it should be done by a USER LEVEL process. Either the controlling process on a PTY, or somehting like the emacs shell window. Please, PLEASE, *PLEASE* don't put BASH or EMACS into the Kernel. Please! :-) Jamie ... Segmentation fault (core dumped) Written On Monday, April 22, 1991 at 04:59:50pm EDT
rhartman@thestepchild.sgi.com (Robert Hartman) (04/24/91)
In article <1991Apr22.210153.16143@gpu.utcs.utoronto.ca> jmason@gpu.utcs.utoronto.ca (Jamie Mason) writes: >gudeman@cs.arizona.edu (David Gudeman) writes: >| Maybe I'm missing something, but it seems to me that many of the Unix >| shells combine two seperable functions: the command language and the >| interactive shell. Is there some advantage to this? It seems to me >| that there would be several advantages to seperating them. > > I use the csh for typing commands. I like it very much ... > ... But for scripts, it should be called the >cs*HELL*. ... > > So I could not agree more -- separate the interactive shell from >the command language. Most of us already have, anyways. I'm not sure that I agree with this, even though I too use csh for typing and sh for scripts--but only if ksh isn't available. While in csh I often use foreach loops and other control structures. One of the most productive design principles in UNIX (and one which I wish had been even more consistently applied) is that every utility is in some sense a programming language. So, what I'd propose instead is that any interactive command interface function as a strict superset of its command language. Also, I'd like to ask that any and all command languages be Turing equivalent and support an arbitrary-length name space. troff is a good example of what not to do. >In article <585@lysator.liu.se> bellman@lysator.liu.se (Thomas Bellman) writes: >>I think this would be good. The proper way to do it, would be to have >>a smarter cooked mode AND let the user load his own cooked mode >>library.... > Yes, I think it isa good idea, but I think it should be done by a >USER LEVEL process. Either the controlling process on a PTY, or >somehting like the emacs shell window. Please, PLEASE, *PLEASE* don't >put BASH or EMACS into the Kernel. Please! :-) > >Jamie ... Segmentation fault (core dumped) >Written On Monday, April 22, 1991 at 04:59:50pm EDT I agree. Actually, once the kernel has the descriptor open for a tty, why should it care how the keystrokes get filtered prior to a RETURN? I don't see how allowing a user-selected editor to process pending input lines could be a security or segmentation problem. Can someone enlighten me if it is? Thanks, -r
src@scuzzy.in-berlin.de (Heiko Blume) (04/24/91)
jmason@gpu.utcs.utoronto.ca (Jamie Mason) writes: > Yes, I think it isa good idea, but I think it should be done by a >USER LEVEL process. Either the controlling process on a PTY, or >somehting like the emacs shell window. Please, PLEASE, *PLEASE* don't >put BASH or EMACS into the Kernel. Please! :-) well, since we'll all have a MACH based OS soon :-), where the now-kernel-builtins will be in seperate system processes, it should be relatively easy to give each user his choice of interaction style. even the users own code could be used, since it will be a normal process, and not part of the kernel. no kernel bloat, no security horror, no memory hogging, easy fixing and improving etc, etc. perhaps a new field in /etc/passwd, or a .discipline file which tells login what to put between the user and his (other) processes for providing <put your feeping-creaturism-capabilities here>. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!] public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
bellman@lysator.liu.se (Thomas Bellman) (04/25/91)
jmason@gpu.utcs.utoronto.ca (Jamie Mason) writes: > In article <585@lysator.liu.se> bellman@lysator.liu.se (Thomas Bellman) writes: >> I think this would be good. The proper way to do it, would be to have >> a smarter cooked mode AND let the user load his own cooked mode >> library. To do this in current Unices I think would be difficult. > Oh. OUCH! Yeah, we will have Tcsh or BASH (!) type stuff in the > cooked mode. TTY aliases. I can just see an IOCTL to do it! And > linking your own cooked mode driver into the Kernel? I imagine it could > come in with a STREAMS module Push. And users could load THEIR OWN CODE > INTO THE KERNEL to do it! Ouch! Uuuggghhh! Hmm, well, I didn't *mean* that they should load it into the kernel. Definitely not. Sorry if I gave that impression. Things should get out of the kernel. The current cooked mode doesn't belong in the kernel either (imho). > Yes, I think it isa good idea, but I think it should be done by a > USER LEVEL process. Either the controlling process on a PTY, or > somehting like the emacs shell window. I think we want the same thing. I'm not very well acquainted with SysV, but from what I've heard about it, the streams concept seems to be rather nice, if they haden't had that stupid restriction that everything you push onto a stream must be in the kernel. If you could push an arbitrary process on top of it, it would be much better. -- Thomas Bellman, Lysator Computer Club ! "Make Love - Nicht Wahr" Linkoping University, Sweden ! "Too much of a good thing is e-mail: Bellman@Lysator.LiU.Se ! WONDERFUL." -- Mae West
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.