mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) (11/30/86)
I know this sort of question has been asked before, but try it again...
I understand that you can stuff chars back into the input stream of
a particular terminal, right? At least on some BSD systems? Well,
how about a hack to vi that lets you do this from the editor? Suppose
you made a macro like this (assuming that ":stuff" stuffs chars):
map ^X :stuff :suspend^M%-^M
The idea being to stuff the sequence of chars that would suspend the vi
job and restart the last previous suspended job. Useful for flipping
between vi's (no flames from /dev/windows or /users/emacs, please)
Can this be done?
--
Larry McVoy mcvoy@rsch.wisc.edu,
{seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy
"They're coming soon! Quad-stated guru-gates!"jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) (11/30/86)
Lawrence W. McVoy <mcvoy@rsch.WISC.EDU> writes:
The idea being to stuff the sequence of chars that would
suspend the vi job and restart the last previous suspended
job. Useful for flipping between vi's.
Neato idea, but to do your specific example needs only the following
keystrokes:
% vi file{0,1}.c
and then ^^ ("control carrot" aka "cntrl-shift-6") will flip flop
you between files ...
As for the other more general idea, I'm sure you could make it work ...
/jordandave@murphy.UUCP (Rael's brother John) (12/01/86)
(In relation to stuffing characters into the terminal input q on BSD systems):
I assume you're talking about TIOCSTI. You could do this, but I think that
vi flushes the input q on a suspend. If you can find where it does this and
remove it, it might work.
---
"I used to be able to sing the blues, but now I have too much money."
-- Bruce Dickinson
Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
UUCP: ...!{sun,pur-ee,brl-bmd,bcopen}!gould!dcornutt
or ...!{ucf-cs,allegra,codas}!novavax!houligan!dcornutt
ARPA: dcornutt@gswd-vms.arpa (I'm not sure how well this works)
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."hutch@sdcsvax.UCSD.EDU (Jim Hutchison) (12/03/86)
<>
You can use TIOCSTI (simulate terminal input), and send what you wish.
I suggest sending "\n:stop\n" to stop vi, this should circumvent that
flushing problem you get with just sending ^Z to vi and letting it deal
with the intterupt. This also gets around the problem of having the
stop character set to something other than ^Z (heaven forbid! :-)
map Q :!yourcommand &^M
You need the \n starter to get out of the "return to continue" message, and
the :stop to get vi stopped. This seems a rather convoluted way to go.
What made a subshell so unsuitable to your needs?
--
=
Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch
ARPA: Hutch@sdcsvax.ucsd.edu
"Yes, yes, ofcourse I disclaim everything. No,no that is not my tape..."dce@quacky.UUCP (David Elliott) (12/04/86)
In article <2270@sdcsvax.UCSD.EDU> hutch@sdcsvax.UUCP (Jim Hutchison) writes: >... > >I suggest sending "\n:stop\n" to stop vi, this should circumvent that >flushing problem you get with just sending ^Z to vi and letting it deal >with the intterupt. This also gets around the problem of having the >stop character set to something other than ^Z (heaven forbid! :-) If you look at the code for ex, you will notice that ^Z and :stop are handled in the same way. That is, the onsusp() routine is called, which just resets the SIGTSTP handler to SIG_DFL, and sends a SIGTSTP to the current process. You can't stop a process in BSD Unix without a signal. In other words, the only difference between ^Z and :stop is what you type. The reason to have :stop is so that you can typeahead long before you enter vi. For example, let's say you are executing some command to create a file that you then need to edit. You might execute the original command in the foreground, type in a couple of more commands, type in the vi command, and some vi commands (such as a search for a pattern). At this point, you realize that you will need to read a manual page. If you type ^Z, you stop now and lose the input you typed ahead. If you type :stop, you will enter vi and stop. Loss of typeahead can really be a pain (this makes the Apollo Domain/IX version of vi, and some of the nicer shell line editors not worth using). I have never found a way to change the handling of signals such that input is not flushed. David decwrl!mips!dce
brett@wjvax.UUCP (Brett Galloway) (12/06/86)
In article <104@quacky.UUCP> dce@quacky.UUCP (David Elliott) writes: > ... If you type ^Z, you stop now and lose the input you typed >ahead. If you type :stop, you will enter vi and stop. Loss of typeahead >can really be a pain (this makes the Apollo Domain/IX version of vi, >and some of the nicer shell line editors not worth using). > >I have never found a way to change the handling of signals such that >input is not flushed. I think that you can use ^Y to embed a stop character in a typed-ahead input stream. -- ------------- Brett Galloway {pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett
rcodi@yabbie.rmit.oz (Ian Donaldson) (12/07/86)
In article <104@quacky.UUCP>, dce@quacky.UUCP (David Elliott) writes: > I have never found a way to change the handling of signals such that > input is not flushed. If your system doesn't have TIOCSETN defined (usually in <sys/ioctl.h>) then you're probably out of luck. Using stty(2) or stty(3) is equivalent to TIOCSETP, that flushes input before changing the modes -- ie: typeahead. stty() is a system call on older versions of UNIX (and SVR2), but a library routine on ones that implement the TIOCSET[NP] ioctl's (eg: bsd derived systems). Similary, for gtty() and TIOCGETP. The 4.2bsd source for vi/ex has a conditional compile of the following nature: #ifdef TIOCSETN ioctl(..., TIOCSETN, ...); #else /* some comment grumbling about problems of typeahead flushing */ stty(..., ...); #endif in the routine that changes tty modes. SVR2 has an equivalent to TIOCSETN, TCSETAW, but it works on a struct termio, instead of struct sgttyb. Ian Donaldson
dce@quacky.UUCP (David Elliott) (12/09/86)
In article <775@wjvax.wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes: >In article <104@quacky.UUCP> dce@quacky.UUCP (David Elliott) writes: >> >>I have never found a way to change the handling of signals such that >>input is not flushed. > >I think that you can use ^Y to embed a stop character in a typed-ahead >input stream. >-- I stand corrected, mainly because I didn't state my case correctly. What I meant was that I know of no way to have a program generate a signal that affects a process without flushing the input. (I've been proven wrong...read on.) In the case of ^Z and ^Y, the difference is that ^Z is handled when it comes into the tty input stream, and ^Y is handled when it is to be handed on to the command. In the case of a command that sends itself a signal, a simple experiment shows that input is not flushed: myprompt% csh % sleep 100 suspend <- typeahead pwd <- typeahead %myprompt% /right/here If we take a look at vi, we see that delayed suspend (^Y) is turned off, and (oh my gosh!) the suspend character is mapped to ^Z (try doing a 'stty susp ^T', run vi, and do a :map; try not to throw up). I think that one way to solve the original problem would be to have some buffer that vi stuffs into the tty driver at suspend time. Any ideas on how to pursue this (not that it's partiularly useful, but it might be fun). David
guy@sun.uucp (Guy Harris) (12/10/86)
> > I have never found a way to change the handling of signals such that > > input is not flushed. > > If your system doesn't have TIOCSETN defined (usually in <sys/ioctl.h>) > then you're probably out of luck. Using stty(2) or stty(3) is equivalent > to TIOCSETP, that flushes input before changing the modes -- ie: typeahead. Yes, but that doesn't seem to be what he was asking for. It looks like he wanted to set things up so that a signal from the tty (SIGTSTP, in this case) didn't cause input to be flushed. There *is* a way to do this, both in 4.2BSD and in S3/S5. In 4.2/4.3, there's a bit (LNOFLSH) that can be set in the local mode word (using TIOCLSET or TIOCLBIS). In S5, the bit is called NOFLSH and is set in the "c_lflag" field of the "termio" structure. In either system, setting this bit causes the terminal driver not to do the normal flush of input (and output, for SIGINT and SIGQUIT) for signals generated from the keyboard. > SVR2 has an equivalent to TIOCSETN, TCSETAW, but it works > on a struct termio, instead of struct sgttyb. Well, actually, TCSETA is the equivalent of TIOCSETN; TIOCSETN neither waits for output to drain nor flushes input. TCSETAW waits for output to drain; TCSETA doesn't. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
cudcv@warwick.ac.uk (Rob McMahon) (12/11/86)
munch >In article <104@quacky.UUCP> dce@quacky.UUCP (David Elliott) writes: >> ... If you type ^Z, you stop now and lose the input you typed >>ahead. If you type :stop, you will enter vi and stop. Loss of typeahead >>can really be a pain (this makes the Apollo Domain/IX version of vi, >>and some of the nicer shell line editors not worth using). >> >>I have never found a way to change the handling of signals such that >>input is not flushed. I tried to reply, but ... What about stty noflsh ? -- UUCP: ...!mcvax!ukc!warwick!cudcv JANET: cudcv@uk.ac.warwick.daisy ARPA: cudcv@daisy.warwick.ac.uk PHONE: +44 203 523037 Rob McMahon, Computer Unit, Warwick University, Coventry CV4 7AL, England
brett@wjvax.UUCP (12/11/86)
In article <107@quacky.UUCP> dce@quacky.UUCP (David Elliott) writes: >In article <775@wjvax.wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes: >>In article <104@quacky.UUCP> dce@quacky.UUCP (David Elliott) writes: >>> >>>I have never found a way to change the handling of signals such that >>>input is not flushed. >> >>I think that you can use ^Y to embed a stop character in a typed-ahead >>input stream. >>-- > >I stand corrected, mainly because I didn't state my case correctly. >What I meant was that I know of no way to have a program generate >a signal that affects a process without flushing the input. (I've >been proven wrong...read on.) Actually, I think there is a way (besides the kludge ^Y). There is an undocumented local mode bit LNOFLSH which, when set, suppresses flushing upon keyboard signals. It is available as 'noflsh` in stty. If you do a stty noflsh, then interrupts won't flush input (or output for that matter). Suppressing flushing output is very useful for programs that do screen management and that trap keyboard signals; without it, the screen management can get trashed. -- ------------- Brett Galloway {pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett