From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stueberl.de!newsfeed.belnet.be!news.belnet.be!news.brutele.be!nmaster.kpnqwest.net!nnum.kpnqwest.net!EU.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: lisp shell ala scsh References: <59db34a7.0205291339.71b0956@posting.google.com> Mail-Copies-To: never From: Erik Naggum Message-ID: <3231699761742658@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 May 2002 22:22:44 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader2.kpnqwest.net 1022710964 193.71.199.50 (Thu, 30 May 2002 00:22:44 MET DST) NNTP-Posting-Date: Thu, 30 May 2002 00:22:44 MET DST Xref: archiver1.google.com comp.lang.lisp:34139 * Lynn H. Quam | Has anyone attempted to implement a "lisp shell" based on scsh, the | "scheme shell", or any of its major components? Yes. In-house only, called CLUNIX. It started out as a collection of various abstractions of the horrible mess that was package management and system administration databases and control variables, then got a little shell. Then it godt stuck in missing a crucial piece, CLEMACS, which, after a long time of study and research was basically relegated to my next life (provided I don't come back as a cat, which I would like). The reason for this is non-obvious. I am not a huge fan of job control as BSD has implemented it, because I want processes output to be in their own space (buffer), to be seen as "values" of programs, and I wanted to keep them around, not just print them on the terminal _or_ pour them down some drain (pipe), as well as controlling the destination buffer of more than one file descriptor. E.g., if you have typed a program name, you might know it has a --help option, but deleting your input line to type that and maybe look at it while you produce a new command, has both interrupted your work flow, it has filled your precious terminal space with junk information, which you should be able to remove once you are doing with it. Likewise, tracing something or requesting verbose running or shell scripts, would naturally go in a different buffer while ordinary output went in an undiluted window. Now the "exitcing" part, I wanted input to be a dialog between the input system and the program, such that as much pre-processing could be done in the shell as possible. (This harkens back to the TOPS-20 CMND JSYS, for those familiar with it, where te exec (command processor) actually called the programs with defined entry points in order to run application code in order to instruct the input parser. I probably made it less than obvious why it is brilliant with this brief statement, so just trust me.) Unix can only fake this by running the program with various half-standardized options, so I had hoped to combine some of Emacs interactive form to communicate this kind of information to a top-level user. All in all there were far too many "good idea" in CLEMACS to keep my concentration, and it was turning into one of those projects that, if it were ever completed, your life would suddenly find itself devoid of meaning. However, I am still young. | If nobody has made a serious effort to implement these aspects of scsh in | Common Lisp, perhaps I should. I realize that much of the work involved | is OS and CL vendor FFI specific, and that it is non-trivial to make this | happed for all Lisp on all OSes. Serious effort would be required to make this _not_ be its own full implementation of Common Lisp. As I see it, it has some properties of a full-blown window system. And well know how much work _that_ is. But rob Bill Gates of a billion for me, and we can work something out. -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief. 70 percent of American adults do not understand the scientific process.