bzs@cs.bu.edu (Barry Shein) (03/21/90)
>One bit drudgery in the bsd world whenever writing programs >(or porting programs to bsd) which manipulate the tty (eg, use >CBREAK) is adding code to reset the ttystate when stopping >(eg, ^Z) and set it again when continuing. > >Why doesn't the csh keep track of this instead? The reply I'm sure you'll hear most is, then how would a program like 'stty' ever work? You'd have to layer more magic to stop the csh from undoing what stty does. Sure, we can make stty a built-in, but that makes it impossible to ever build another program which does this (and people do this kind of thing more than you might think, such as little programs or scripts to switch between two tty modes, such as when using a graphics capable terminal.) The second most frequent reply you will get is that foosh does just what you describe (where "foo" is replaced by two or three chars.) Of course, that doesn't make it a particularly good idea! It's a hard design problem and given the current state of the world would probably be better solved by writing a little library routine to handle what you want rather than re-working the OS. I'd be curious to hear how those shells that do this handle the stty problem. -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
karl_kleinpaste@giza.cis.ohio-state.edu (03/22/90)
bzs@cs.bu.edu writes:
The reply I'm sure you'll hear most is, then how would a program like
'stty' ever work? You'd have to layer more magic to stop the csh from
undoing what stty does.
Not really...
I'd be curious to hear how those shells that do this handle the stty
problem.
The SysV csh I built took care of the problem reasonably trivially.
When a job _stopped_, csh would restore the tty state it knew before
the job was started. When the job was restarted, csh would re-assert
the tty state it had when the job last stopped.
When a job _ended_, the tty state was not messed with, on the
assumption that the job knew what it was doing if it changed things.
stty works fine on this basis. And things like Emacs and vi could be
stopped without causing confusion.
It was very useful to be simulating job control in a non-job-control
environment when dealing with this problem, since I had to assume that
the job had no clue whatever that it might possibly be stopped; csh's
interaction with such stuff had to be completely transparent.
--karlsteve@nuchat.UUCP (Steve Nuchia) (03/22/90)
In article <KARL.90Mar21140133@giza.cis.ohio-state.edu> karl_kleinpaste@giza.cis.ohio-state.edu writes: >The SysV csh I built took care of the problem reasonably trivially. >When a job _stopped_, csh would restore the tty state it knew before ... >When a job _ended_, the tty state was not messed with, on the >assumption that the job knew what it was doing if it changed things. Hey, make it restore when the job abends and you've got a friend for life. Certainly if it dies of a signal, and I'd be happy with it resetting on any non-zero exit. Of course there is probably some broken program somewhere that wouldn't be happy with it, but wtf. I've actually built a trivial shell that wrapped a stty restore around a system(gets()) to use when testing ioctl-intensive code. Particularly when working on the console of a terminal-less system :-( -- Steve Nuchia South Coast Computing Services (713) 964-2462 "You have no scars on your face, and you cannot handle pressure." - Billy Joel
tchrist@convex.COM (Tom Christiansen) (03/22/90)
In article <22821@adm.BRL.MIL> bzs@cs.bu.edu (Barry Shein) writes: >I'd be curious to hear how those shells that do this handle the stty >problem. I think the best thing to do is to have the shell always restore the mode to what it was before the program was called, irrespective of whether the program should have stopped, exited, or aborted. In order to handle the stty case, you can introduce a variable to control this, in the style of noglob and nonomatch. Let's call this noreset. Thus, % set noreset; stty kill ^g; unset noreset I've actually worked with (t?)csh's that had this feature, but I don't recall precisely where. --tom -- Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
mike@turing.cs.unm.edu (Michael I. Bushnell) (03/23/90)
In article <20741@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >Hey, make it restore when the job abends and you've got a friend ^^^^^^ AAUUUGGGHHH!!!!!NO! Stamp out language abuse! The Ignorant Blue Momma company invents bogus words, and then UNIX people start using them! NO NO NO!! HELP! Sigh. >for life. -- Michael I. Bushnell \ This above all; to thine own self be true LIBERTE, EGALITE, FRATERNITE \ And it must follow, as the night the day, mike@unmvax.cs.unm.edu /\ Thou canst not be false to any man. CARPE DIEM / \ Farewell: my blessing season this in thee!
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/23/90)
In article <100777@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >I think the best thing to do is to have the shell always restore >the mode to what it was before the program was called, irrespective ... Yup, that's how we do it in the BRL shell when command-line editing (and history) are enabled. As to stty, we simply made it a builtin that merely invoked the real one but keeps track of the new non-prompt tty state that results. The way I actually look at it is that the "vanilla" tty state is established for programs that are executed, the "fancy" state is (of necessity) exactly that which the shell needs for its own (command-line editing and job control) purposes, and "stty" changes the "vanilla" state only.
aryeh@eddie.mit.edu (Aryeh M. Weiss) (03/23/90)
In article <KARL.90Mar21140133@giza.cis.ohio-state.edu> karl_kleinpaste@giza.cis.ohio-state.edu writes: ... >Not really... > > I'd be curious to hear how those shells that do this handle the stty > problem. > >The SysV csh I built took care of the problem reasonably trivially. >When a job _stopped_, csh would restore the tty state it knew before >the job was started. When the job was restarted, csh would re-assert >the tty state it had when the job last stopped. > >When a job _ended_, the tty state was not messed with, on the >assumption that the job knew what it was doing if it changed things. > Csh already has "prefixes" like "nohup `command'" or "time `command'". How about a prefix like "condom `command'", which would save the tty state before the command is run and restore it after to a "safe" state (:-). This would be useful for debugging software that changes the tty state but may still be prone to crash before it gets a chance to restore the modes. --
chip@tct.uucp (Chip Salzenberg) (03/24/90)
According to tchrist@convex.COM (Tom Christiansen): >I think the best thing to do is to have the shell always restore >the mode to what it was before the program was called, irrespective >of whether the program should have stopped, exited, or aborted. This is almost what tcsh does; I like it. Tcsh doesn't try to restore modes. Instead, it notes *changes*. It obeys the sane ones for command line editing while leaving the rest in place for other hapless applications. :-) For example, "stty erase '^?'" affects the tcsh backspace operation, but "stty -echo" doesn't. However, the "stty -echo" *will* affect other programs. No, it's not perfect, but at least it prevents weird modes that keep you from typing "stty sane". -- Chip Salzenberg at ComDev/TCT <chip%tct@ateng.com>, <uunet!ateng!tct!chip> "The Usenet, in a very real sense, does not exist."
peter@ficc.uu.net (Peter da Silva) (03/24/90)
> Csh already has "prefixes" like "nohup `command'" or "time `command'". > How about a prefix like "condom `command'", which would save the tty state > before the command is run and restore it after to a "safe" state (:-). alias condom 'stty -g >! /tmp/stty'$$' ; \!* ; sh -c '"'"'stty `cat /tmp/stty'$$'`'"'" All the weird quotes are thanks to an unforgiving shell. It'd be easier as as shell script, but then you couldn't condom aliases. If there was a *real* inverse to stty -g (i.e., reading from stdin) it'd help a lot. -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ 'U` \_.--._/ v
blm@6sceng.UUCP (Brian Matthews) (03/24/90)
In article <KARL.90Mar21140133@giza.cis.ohio-state.edu> karl_kleinpaste@giza.cis.ohio-state.edu writes: |The SysV csh I built took care of the problem reasonably trivially. |When a job _stopped_, csh would restore the tty state it knew before |the job was started. When the job was restarted, csh would re-assert |the tty state it had when the job last stopped. |When a job _ended_, the tty state was not messed with, on the |assumption that the job knew what it was doing if it changed things. I did something similar, but also had the shell restore the state if the process exited due to a signal, presuming someone killed it and it may not have had a chance to clean up. I suppose it's conceivable that a program could be written that killed itself as a normal exit procedure, but I haven't yet come across a program that badly written :-) -- Brian L. Matthews blm@6sceng.UUCP
datri@convex.com (Anthony A. Datri) (03/25/90)
In article <MIKE.90Mar22145838@turing.cs.unm.edu> mike@unmvax.cs.unm.edu writes: =In article <20741@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: ==Hey, make it restore when the job abends and you've got a friend =Stamp out language abuse! The Ignorant Blue Momma company invents =bogus words, and then UNIX people start using them! NO NO NO!! Why not? AIX speaks of ipl'ing, after all:-)