cottrell@nbs-vms.ARPA (01/04/85)
/* let's start a new discussion... we just received sys v here on a vme10 (bfd). of course there is no csh. in the fabled oct bstj kernighan (or was it ritchie) decries the practice of history (& alias?) only for csh commands. he says why not for *all* input, including that for programs. okay, bizarre idea time. how about writing a filter that only does aliases & history & pipes the transformed output to sh! so far so good, *but* then interactive progs like vi (yes, its in sys v) won't run because they attempt to do ioctl/stty on a pipe. this means i have to save the stdin fd & exec vi directly. any suggestions, comments? maybe i can get a rise out of chris@md on this one. "feets dont fail me now" -- bokonan piggyback ack: hello bro! */
chris@umcp-cs.UUCP (Chris Torek) (01/05/85)
Hmmm.... a "history preprocessor"...
Well, to get around the pipes problem, you could always use ptys (does
System V *have* ptys?). But I wonder what exactly "history" means in
a program like VI or Emacs. If you take the C shell history mechanism
(please! :-) ) as your base idea, then you have "lines" of stuff with
a "redo this line with the following changes" command, which doesn't
seem to be too useful with screen editors.
--
(This line accidently left nonblank.)
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandrobert@gitpyr.UUCP (Robert Viduya) (01/08/85)
>< > Hmmm.... a "history preprocessor"... > > Well, to get around the pipes problem, you could always use ptys (does > System V *have* ptys?). But I wonder what exactly "history" means in > a program like VI or Emacs. If you take the C shell history mechanism > (please! :-) ) as your base idea, then you have "lines" of stuff with > a "redo this line with the following changes" command, which doesn't > seem to be too useful with screen editors. The trick is to generalize it. Define "history" as a list of previously typed strings, which, for simplicity's sake, we'll call "events". Input events are defined and seperated by output _t_o the terminal. This means that, from the shell, an event would be a command line, because, after a command is typed, output from the command or the appearance of a prompt would seperate it from the next command line. In a screen editor, an event would be anything that changes the appearance of the screen, because changing the screen would mean that something was sent to the terminal. Obviously, this is not as simple as it sounds. Character echoing should not be considered as output to the terminal and, hence, is not an event seperator. Since most screen editors handle their own echoing, this is more of a problem than it seems. Also, a more transparent method of calling up previous events is necessary. Perhaps YA terminal control character (user-defineable via stty, of course). robert -- Robert Viduya Office of Computing Services Georgia Institute of Technology, Atlanta GA 30332 Phone: (404) 894-4669 ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
geoff@desint.UUCP (Geoff Kuenning) (01/08/85)
In article <6986@brl-tgr.ARPA> cottrell@nbs-vms.ARPA writes: >okay, bizarre idea time. how about >writing a filter that only does aliases & history & pipes the transformed >output to sh! so far so good, *but* then interactive progs like vi (yes, >its in sys v) won't run because they attempt to do ioctl/stty on a pipe. >this means i have to save the stdin fd & exec vi directly. any suggestions, >comments? maybe i can get a rise out of chris@md on this one. This is easy to do if you have pseudo-tty's. My machine has these even though I don't have networking (this is a fortuitous side effect), and I normally run my normal tty through a program that talks to 4 pseudo-tty's (poor man's job control). It would not be hard to replace it with a fancy screen-oriented guy that managed windows, kept history, and the whole bit, for all terminal interactions. One advantage of this sort of approach is that tty settings become associated with the subject process, rather than the tty. After all, why should my cat's be screwed up just because I ran vi? And why should vi have to go to a lot of work to put the tty back the way cat wants it, every time I send it a SIGTSTP? One problem is the massive-input problem: When I am editing, I *don't* want history (the features of a good editor are much more useful than a history of edit commands), and I most certainly don't want my two hours of entering code to wipe out my command history. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
breuel@harvard.ARPA (Thomas M. Breuel) (01/10/85)
Why don't you just use EMACS? It provides history and editing capabilities for a shell in a buffer. Thomas. PS: I have been using EMACS for a while, but I'm back to ed now...
gregbo@houxm.UUCP (Greg Skinner) (01/17/85)
EDT under VMS has a mechanism which logs all commands that went to the terminal
during the editing session. It writes out a file with all the commands. If
for some reason the session is aborted, the user may specify that his state
be restored before the abort by having the log file run.
I don't know how this could be extended to vi/emacs as far as a history pro-
gram with indexing backwards/forwards through the issued commands, but that
would be a start, I guess. I don't know for sure, but the rogue.save file may
be of similar structure (if not format) -- it's certainly large enough to con-
tain a history of commands.
--
Baby tie your hair back in a long white bow ...
Meet me in the field, behind the dynamo ...
Greg Skinner (gregbo)
{allegra,cbosgd,ihnp4}!houxm!gregbo