roseann@polyof.poly.edu (RoseAnn Ammendolea) (10/19/90)
I am working on a senior project to rewrite the history function for UNIX. My goal is to have the new history functon work like it does in MS_DOS.
i.e. I want to be able to call up past commands and edit them by using the
control <hjkl> characters. Additionally, I would like to write this as a stand alone program so that I do not have to rewrite the shell.
The main approach I will use will be to store the previous commands in alinked list. My only problem is that I do not know how to intercept the commandonce it has been entered, before it gets executed. Likewise, I do ont know how to execute the command once I have retreived it form the list. i.e. I want to display the command for possible editting and execute it when the carriage
return is pressed.
If there is anyone out there that has some ideas or suggestions, they would be greatly appreciated. Also if anyone knows where I might be able to find the source code for the present HISTORY function or the R function I would like to know so I can look at it and gain some insight to my project.
P.S. Please do not send replys to posters address use the address in the
reply-to header.
Thank You. Markwcs) (10/21/90)
In article <1990Oct19.165721.7584@polyof.poly.edu>, roseann@polyof.poly.edu, (RoseAnn Ammendolea) (or Marc someone using her account?) writes: ] I am working on a senior project to rewrite the history function for UNIX. ] My goal is to have the new history function work like it does in ] MS_DOS. i.e. I want to be able to call up past commands and edit them ] by using the control <hjkl> characters. Additionally, I would like to ] write this as a stand alone program so that I do not have to rewrite the shell. The main problem is that UNIX doesn't process or remember the command lines, (except to the crude extent that the accounting system does) - it's all done by the shell. The commands you type are simply input to the shell, which does any interpretation, and fork()/exec()s the command if it's a "real" command, or just does it if it's a shell builtin. Depending on what shell you use, it may or may not have a history capability, and that history may be stored in a file or in memory. If it's in a file, it may not be absolutely up-to-date. You'll have to play around with shells you like, and you really need source. The old Bourne shell (/bin/sh) doesn't do history. The C shell does, with the ugly !! command-based interface. The Korn shell (ksh) does history, stores it in a file, and gives you an editor-interface as well as a command-based interface. Various intellectual derivatives like BASH and tcsh are similar. The 9th edition shell gave you something lean, mean, and clean, as always. The adventure shell doesn't have history, but it has xyzzy. :-) MS-DOS itself doesn't have a 'history' command. The F1 and F3 keys let you get the most recent command, unless it's been trashed; I think this is managed by command.com rather than DOS. There are a couple of history commands running around, including HISTORY and ANARKEY; don't know if any of them come with source. The other good thing about VMS, besides HELP, was command editing. It probably only worked for VT100 terminals, but it was there and easy. Good luck -- Thanks; Bill # Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ Government is like an elephant on drugs: It's very confused, makes lots of noise, can't do anything well, stomps on anyone in its way, and it sure eats a lot.
psmielke@lotus.uwaterloo.ca (Peter Mielke) (10/22/90)
In <1990Oct19.165721.7584@polyof.poly.edu>, mhoffman@george.poly.edu writes: > > I am working on a senior project to rewrite the history function for > UNIX. My goal is to have the new history functon work like it does in > MS_DOS. i.e. I want to be able to call up past commands and edit them > by using the control <hjkl> characters. Additionally, I would like to > write this as a stand alone program so that I do not have to rewrite > the shell. > If you are in the csh you don't have to write such a creature, one already exists: ----------cut here------------ # Edit history list at line containing last command (open mode). # Get up to 22 most recent commands. # To work properly, put in .login: alias r source /usr/local/bin/redo # Author unknown. # history -h 22 >! /tmp/redo.$$ # history -h 22 | grep -v '^r$' >! /tmp/redo.$$ # # Make CR map to :wq! and start ex quietly at 2nd to last line in open mode. # ex - '+map ex - '+map # # have to show output so tty works # # ex '+map # tail -1 /tmp/redo.$$ >! /tmp/cmd.$$ # # Insert into history without executing. # source -h /tmp/cmd.$$ # # Clear out temporaries. # /bin/rm -f /tmp/{cmd,redo}.$$ # # If thing chosen to redo is the redo alias itself then DON'T redo it. # if (!-2:0 != !!:0) !! ----------cut here------------ -- Peter Mielke Preferred -> psmielke@lotus.UWaterloo.ca University of Waterloo peter@doe.utoronto.ca An undergrad that's been around too long...
ti@altos86.Altos.COM (Ti Kan) (10/24/90)
In <1990Oct19.165721.7584@polyof.poly.edu>, mhoffman@george.poly.edu writes: > > I am working on a senior project to rewrite the history function for > UNIX. My goal is to have the new history functon work like it does in > MS_DOS. i.e. I want to be able to call up past commands and edit them > by using the control <hjkl> characters. Additionally, I would like to > write this as a stand alone program so that I do not have to rewrite > the shell. Perhaps it is useful to you to write such a thing for your senior project, but it seems like such a waste of effort when you can just use ksh (Korn Shell) that already has command history editing capability. Anyway, this will be difficult without incorporating the functionality into the shell. You can't really intercept keyboard input with a user program before the shell gets it, unless you have a really weird tty driver. Also, how do you distinguish shell commands from keystrokes typed during the run of an application? -Ti -- Ti Kan | vorsprung durch technik! \\\ Internet: ti@altos.com \\\ UUCP: ...!{sun|sco|pyramid|amdahl|uunet}!altos!ti /// \\\ The opinions herein are not necessarily those of Altos. ////////\
staff@cadlab.sublink.ORG (Alex Martelli) (10/24/90)
wcs@cbnewsh.att.com (Bill Stewart 201-949-0705 erebus.att.com!wcs) writes: ... >The main problem is that UNIX doesn't process or remember the command lines, It doesn't, but then again, it MIGHT! There's a line-discipline called CLED (Command Line Editing Discipline?), that was posted to some source newsgroup within the last year or so, to do just that - history and reasonable editing, NOT just erase and kill, for any process reading /dev/tty in canonical mode. I have not been able to install it, but the concept appears to be sound. >You'll have to play around with shells you like, and you really need source. I believe source for a sh lookalike was posted to some source group too, maybe comp.sources.unix in or around volume 19; it may be easier to work with than something more complex like ksh, yashell, etc. Source for a VERY bare-bones subset of sh is in Rochkind's wonderful book "Advanced Unix Programming" (if you haven't mastered the concepts it displays, you're not a Unix programmer; if you have, you owe it to yourself to read the book anyway - it's an enjoyable experience, on a par with other classics in technical literature such as "The Unix Programming Environment" and "The C Programming Language"). Given Rochkind's didactical purposes, this subset may be even better than the full sh in volume 19, IFF the exercise is in a school setting; for real-world purposes, of course, featuritis may be needed. If you want to *redesign* a Unix shell, rather than starting from available sources, look at the specs for "rc", Plan 9's shell, in the proceedings of the UKUUG conference held in London last July; rc's sources MIGHT even be available at some time in the future, but I'm told not to hold my breath while AT&T's accountants figure out if this would be A Good Thing - on the other hand, the specs and rationale ARE there right now, and a good design it appears to be (I don't know what "look-and-feel" intellectual-property laws and strictures might apply, of course). -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only; any time of day or night).
bpendlet@bambam.UUCP (Bob Pendleton) (10/25/90)
From article <1990Oct21.010205.24695@cbnewsh.att.com>, by wcs@cbnewsh.att.com (Bill Stewart 201-949-0705 erebus.att.com!wcs): > In article <1990Oct19.165721.7584@polyof.poly.edu>, roseann@polyof.poly.edu, > (RoseAnn Ammendolea) (or Marc someone using her account?) writes: > ] I am working on a senior project to rewrite the history function for UNIX. > The other good thing about VMS, besides HELP, was command editing. > It probably only worked for VT100 terminals, but it was there and easy. I wrote a program called ile (input line editor) a few years ago that implements VMS style command line and history editing in unix. I then extended it to give you an emacs like history editing interface. It works by using a pty/tty pair to wedge itself between the user and the program you are using. I'll send a copy to anyone who asks. Bob P. -- Bob Pendleton, speaking only for myself. bpendlet@dsd.es.com or decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet X: Tools, not rules.
meissner@osf.org (Michael Meissner) (11/01/90)
In article <4288@altos86.Altos.COM> ti@altos86.Altos.COM (Ti Kan) writes: | In <1990Oct19.165721.7584@polyof.poly.edu>, mhoffman@george.poly.edu writes: | > | > I am working on a senior project to rewrite the history function for | > UNIX. My goal is to have the new history functon work like it does in | > MS_DOS. i.e. I want to be able to call up past commands and edit them | > by using the control <hjkl> characters. Additionally, I would like to | > write this as a stand alone program so that I do not have to rewrite | > the shell. ... | Anyway, this will be difficult without incorporating the functionality | into the shell. You can't really intercept keyboard input with a user | program before the shell gets it, unless you have a really weird | tty driver. Also, how do you distinguish shell commands from | keystrokes typed during the run of an application? Actually on BSD systems, it is somewhat straight forward. You make the history function be a pty master, and spawn the shell with the slave pty as it's /dev/tty. In fact's it was submitted to the moderated group comp.sources.unix about 1-2 years ago. Remember that UNIX is not the same thing on all platforms -- if your system doesn't have a useful feature, it doesn't necessarily mean that my system must not have that feature..... -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/03/90)
In article <MEISSNER.90Oct31182112@osf.osf.org> meissner@osf.org (Michael Meissner) writes: > Actually on BSD systems, it is somewhat straight forward. You make > the history function be a pty master, and spawn the shell with the > slave pty as it's /dev/tty. It's now exceedingly straightforward, as the ``pty'' program will handle all the details of pseudo-terminal allocation and management. See pmlined, just posted to alt.sources, for an example of how easy it is to implement a line discipline using pty. Feel free to play with pmlined and add features. ---Dan