Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!lll-winken!iggy.GW.Vitalink.COM!widener!news.cs.indiana.edu!arizona.edu!arizona!gudeman From: gudeman@cs.arizona.edu (David Gudeman) Newsgroups: comp.unix.shell Subject: Re: separate the command language and interactive Message-ID: <2832@optima.cs.arizona.edu> Date: 7 May 91 06:19:15 GMT Sender: news@cs.arizona.edu Lines: 56 In article <-#8Gd-e*1@cs.psu.edu> Felix Lee writes without understanding anything that he is replying to: ]> ::= * | "set" = ]> ::= "-"* | "$" | ]> path-complete with "echo $path" ]> path-complete with "pwd" ]> list-complete 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!gudeman