Newsgroups: comp.unix.shell Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!lethe!tvcent!comspec!scocan!john From: john@sco.COM (John R. MacMillan) Subject: Re: separate the command language and interactive shell Organization: SCO Canada, Inc. Date: Fri, 10 May 1991 18:47:07 GMT Message-ID: <1991May10.184707.13965@sco.COM> References: <2987@optima.cs.arizona.edu> Sender: news@sco.COM (News administration) I think we're probably going to have to end up calling this a religious issue, and agreeing to disagree, but I'll try to address your points. David Gudeman writes: |]|I can make the syntax as complex as needed and do file completion with |]|any characters. |] |]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? | |There are two possible answers to this. First, the input of almost |every interactive line-oriented program can be described with a CFG. |CFG's are well-understood, easy to write, and easy to use, so you |_can_ describe the full language if necessary. I think what you're saying requires the ish to recognize which clang is running (hence which CFG to use), either by trying to have the ish recognize them, or by explicitly telling the ish. In many ways, this issue is like Felix's concern about how to tell which is the current interactive process; in our method, in order to communicate with it, and in your method to determine which CFG to use. |Alternatively, _I_ |would prefer an ish that more or less ignored vagaries in file syntax |-- giving a uniform way to reference files across programs. For |example ~ and ~ get expanded by the ish. Clangs don't have to |understand them at all. And those clangs that are already writen that |don't understand these get added functionality just by running under |the ish. That's certainly a big advantage in your scheme, although clangs that don't have the ``echo $pwd'' capability still have to use the ish current working directory for completion, so it's not as big a win in those cases. |]$ ls -l ${foo%a*}ogus. | |I don't see anything difficult here either. What I was getting at was that ${foo%a*} is a powerful ksh construct that I want access to when completing. And I want ${foo:t} when using csh. And I want $foo(3 5) when using rc. I don't think it's reasonable to have ish support all these. That, I think, is where we differ. You would prefer a consistent interface to the clangs, and I would prefer to have all the clang features available to me. My way does require more clang cooperation than yours, so is less suitable as a short term solution. |]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). | |Completion is something that is completely worthless in a batch job. |That implies to me that it is an interactive function that belongs in |the interactive shell. But all the clangs are already interactive, or you wouldn't be running them under ish; they may be suitable for batch jobs as well, and in those cases, the completion support is extra bulk, but so is putting out prompts, etc. |]Again, what wild cards? Csh-like, sh-like, ksh-like? I don't want |]the ish to force this on all my clangs. | |I do. I want wild-card interpretation to be consistent across all |programs that I use under the ish -- just like all the other |interactive conviences. But if the clang writer is serious about it, |these syntactic peculiarities can be included in the command-line |description. The clang can still do all of the completion if the |writer wants to. Again we differ in the same way; you want consistency, and I want the full power of each clang. |Lets not exaggerate the difficulty of writing a BNF description. It |is certainly not as "ugly" as writing interactive features into all |line-oriented programs. A matter of where you want your ugly. :-) I'd rather have the clangs do completion to get their full expressive power. I think trying to put that power, even for something as ``simple'' as variable expansion, into the ish is ugly. |... (I don't know what you mean by "conflicting" |syntax. Conflicting with what?) With other clangs. At that time I had not realized that you wanted the ish to recognize which clang was running and use the appropriate CFG. |]I disagree. Completion is context-dependent on how the clang is going |]to interpret the command-line | |That depends on your model of completion. Some ish's may only have |filename completion -- and only on files with ish syntax. Right, and I think we have different models of completion. |]doesn't really make the clang harder | |Then how come so few programs have it? Because it's of no value without a cooperating raw mode interface. A completion command is not really any use if it's not convenient, and without an ish, it simply wouldn't be convenient. |]... 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. | |In my system only one program --the ish-- has to do file completion. |And file completion is the hardest kind to to. In your scheme, |practically every program has to include the fairly substantial amount |of code necessary to complete file names (or have no completion at |all) and that code is only useful in interactive situation. For |programs that are fequently run in batch mode the file completion code |is dead weight. I think the notion of completion is clang-dependent. Filename completion is a very common instance, and it seems tempting to try and move it into the ish, because so many programs want to do it. However doing it that way sacrifices clang-power that can express filenames unless you duplicate the clang functionality in the ish, which means dead weight that way. Ideally, the ``dead weight'' completion code that is indeed common (scanning the directory and matching) never gets paged in when the program is running in batch mode. And if you put it in a shared library, it doesn't even take up disk space. |My scheme has the advantage that it is completely upward compatible |and transparent to existing programs. And programs can be made to |work better with the ish without changing the program at all. A user |that has a program that he wants to work better with the ish can just |write a description file that handles the features that user wants. Yes, this is true. In fact I would probably put very rudimentary filename completion in my ish, so that when the clang was non- cooperating, at least _something_ would be available to the user. |]Actually it still has the problem of hiding the communication with the |]clang if you want to do that. | |I don't understand what you mean. Your CFG tells you the user is trying to complete a filename, so you do an ``echo $pwd'' (in the defined per-clang way, if there is one) and read the result, to get the clang's notion of the current directory. I'd rather not see that transaction, and hiding it can get rather messy. (This same problem makes me lean toward having a completely separate communication channel for my method.) |... I'm using a perfectly useful ish right |now that doesn't parse command lines. It only completes file names |and only understands shell variables and ~, but it is a lot nicer than |any Unix shell I know of. And I didn't have to do anything to the csh |that runs under it. It's called cmushell and runs under GNU Emacs. Part of what has gotten me thinking about this is that cmushell/emacs is exactly what I don't want. :-) In deciding why that was the case, I felt that it was because the ish was trying to do too much. As I said at the start, I guess we'll just have to agree to disagree. You go your ish, and I'll go mine. :-)