Path: utzoo!attcan!uunet!husc6!bloom-beacon!athena.mit.edu!tytso From: tytso@athena.mit.edu (Theodore Y. Ts'o) Newsgroups: comp.unix.wizards Subject: Re: Input Line Editing Message-ID: <6264@bloom-beacon.MIT.EDU> Date: 17 Jul 88 16:59:09 GMT References: <6192@bloom-beacon.MIT.EDU> <919@esunix.UUCP> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: tytso@athena.mit.edu (Theodore Y. Ts'o) Organization: Massachusetts Institute of Technology Lines: 53 In article <919@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes: >From article <6192@bloom-beacon.MIT.EDU>, by tytso@athena.mit.edu (Theodore Y. Ts'o): >> were typed to that tty. For example, if you started editing a file >> using /bin/ed (or some other interactive program), and typed hundreds >> of "n", "p", "i", "a", and "s/foo/bar/" commands, when you exited to >> the shell, do you really want to step through those hundreds of /bin/ed >> commands? The shell isn't going to do anything useful with them. What > >If ed sets cbreak or raw mode then ile won't record any of the >characters going either direction. That wasn't the point. You know as well as I do that /bin/ed doesn't turn on cbreak or raw mode. The point was that I didn't want /bin/ed's (or any other interactive program) mixing with the history of the shell. The fact that ile does the right thing with emacs is wonderful, but it doesn't obscure the above problem. >On the other hand in some programs you might like to have a history >and line editing capability but not have that history in your "global" >history. So, just invoke "ed" as "ile ed" or even alias "ed" to "ile >ed". Then while you are running ed you have a local history that goes >away as soon as you exit ed. But, the input line editing stays >consistent. That's certainly a solution. One thing I've discovered since my last posting is that ile co-exists quite peacefully with a shell with built-in line editing. This way, you can have the best of both worlds. A hack which I'm thinking about designing for our shell is a builtin which would fork a copy of shell and have it work in the same manner as ile does for a certain command. This way, while you're in the shell, you don't get the efficiency hit of a pty pair, and the user can set up his keybindings and his keymaps at will. Then, when he wants line editing for an interactive program, the line editing environment will be duplicated. This allows a user to modify his line editor on the fly, and have the changes be reflect the next time he wants line editing. >I can't force my users to use one shell. I don't have time to hack several >shells. Especially since I don't think I have source for all of them. >And I can't count on having shell source in the future. I can count on >having the source to ile. We aren't all still in academia. Well, we could induce Berkeley (and other vendors) to put some sort of user-customizable line editior in the next csh. Or, you could just run GNUemacs in shell mode.... you should always have source code for that :-) - Ted =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o mit-eddie!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu If it's for real, it isn't!