Hi,

Here is a little C-program that sets the terminal into raw mode and
waits for 10 seconds for the user to press Ctr-C.  When that happens, a
signal handler is invoked that calls exit(2).

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <termios.h>
#include <unistd.h>

void sighandler(int /*sig*/)
{
exit(2);
}

int main()
{
signal(SIGINT, sighandler);  // Without this, terminal is reset!
termios termio;
tcgetattr(0, &termio);
termio.c_iflag &= ~( BRKINT | PARMRK | INPCK | IXOFF );
termio.c_iflag |=  ( IGNBRK | IGNPAR );
termio.c_lflag &= ~( ICANON | ECHO | ECHOE | ECHOK | ECHONL );
termio.c_lflag |=  ( ISIG );
tcsetattr(0, TCSADRAIN, &termio);
fprintf(stderr, "Now hit Ctrl-C\n"); fflush(stderr);
sleep( 10 );
}

If I do that on my SuSE Linux box, the terminal is left in a very
strange mode. Okay, I expected that, since I didn't write any code to
restore the terminal to its orginal settings. However, with the default
signal hander active, the terminal is magically reset.

My question is: who resets the terminal? Bash? Readline? The Great
SIG_DFL Handler(tm)? A conspiration thereof? Anyone else?

Thanks in advance
-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>

[ Post a follow-up to this message ]

<richard.kreckel@framatome-anp.com> wrote in message
news:1150475871.145035.102860@h76g2000cwa.googlegroups.com...
> Hi,
>
> Here is a little C-program that sets the terminal into raw mode and
> waits for 10 seconds for the user to press Ctr-C.  When that happens, a
> signal handler is invoked that calls exit(2).
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <signal.h>
> #include <termios.h>
> #include <unistd.h>
>
> void sighandler(int /*sig*/)
> {
>    exit(2);
> }
>
> int main()
> {
>    signal(SIGINT, sighandler);  // Without this, terminal is reset!
>    termios termio;
>    tcgetattr(0, &termio);
>    termio.c_iflag &= ~( BRKINT | PARMRK | INPCK | IXOFF );
>    termio.c_iflag |=  ( IGNBRK | IGNPAR );
>    termio.c_lflag &= ~( ICANON | ECHO | ECHOE | ECHOK | ECHONL );
>    termio.c_lflag |=  ( ISIG );
>    tcsetattr(0, TCSADRAIN, &termio);
>    fprintf(stderr, "Now hit Ctrl-C\n"); fflush(stderr);
>    sleep( 10 );
> }
>
> If I do that on my SuSE Linux box, the terminal is left in a very
> strange mode. Okay, I expected that, since I didn't write any code to
> restore the terminal to its orginal settings. However, with the default
> signal hander active, the terminal is magically reset.
>
> My question is: who resets the terminal? Bash? Readline? The Great
> SIG_DFL Handler(tm)? A conspiration thereof? Anyone else?
>
> Thanks in advance
>  -richy.
> --
> Richard B. Kreckel
> <http://www.ginac.de/~kreckel/>
>

Your program is responsible for restoring the terminal state.  I would
recommend copying your original termios struct (just after tcgetattr) into a
global, and using that to restore the appropriate flags within the signal
handler.

--

Fletcher Glenn

[ Post a follow-up to this message ]

> Your program is responsible for restoring the terminal state.  I would
> recommend copying your original termios struct (just after tcgetattr) into
 a
> global, and using that to restore the appropriate flags within the signal
> handler.

That's beside the point: Something *is* restoring it for me. I would be
interested knowing what that is?

[ Post a follow-up to this message ]

>> Your program is responsible for restoring the terminal state.  I would 
>
>That's beside the point: Something *is* restoring it for me. I would be
>interested knowing what that is?

Sometimes shells do it.  For example, csh on FreeBSD 6.0 seems to
do it.  (maybe only interactive shells) Type "stty -echo" twice,
and the second one echos.  I'm also not sure exactly WHAT it restores,
and to what value.  It does turn echo back on.  It also seems to turn
icanon back on.

Gordon L. Burditt

[ Post a follow-up to this message ]

"Gordon Burditt" <gordonb.4054j@burditt.org> wrote in message
news:12965ij8hdldr68@corp.supernews.com... 
>
> Sometimes shells do it.  For example, csh on FreeBSD 6.0 seems to
> do it.  (maybe only interactive shells) Type "stty -echo" twice,
> and the second one echos.  I'm also not sure exactly WHAT it restores,
> and to what value.  It does turn echo back on.  It also seems to turn
> icanon back on.
>
> Gordon L. Burditt

After a program crash, I've sometimes found it necessary to enter the
character sequence:

^Jreset^J

This will reset the tty to a roughly sane state.

--

Fletcher Glenn

[ Post a follow-up to this message ]

Fletcher Glenn wrote:
> After a program crash, I've sometimes found it necessary to enter the
> character sequence:
>
> ^Jreset^J
>
> This will reset the tty to a roughly sane state.

You can also do

^Jstty sane^J

At least that's what I do when I'm in such a situation.

- Logan

[ Post a follow-up to this message ]

In article <12965ij8hdldr68@corp.supernews.com>,
gordonb.4054j@burditt.org (Gordon Burditt) wrote:
 
>
> Sometimes shells do it.  For example, csh on FreeBSD 6.0 seems to
> do it.  (maybe only interactive shells) Type "stty -echo" twice,
> and the second one echos.  I'm also not sure exactly WHAT it restores,
> and to what value.  It does turn echo back on.  It also seems to turn
> icanon back on.

I think most shells that provide real-time (e.g. emacs-style) input
editing will reset the terminal state, because they require their own
special state rather than the normal default state.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

On 2006-06-17, Barry Margolin wrote:
> In article <12965ij8hdldr68@corp.supernews.com>,
>  gordonb.4054j@burditt.org (Gordon Burditt) wrote:
> 
>
> I think most shells that provide real-time (e.g. emacs-style) input
> editing will reset the terminal state, because they require their own
> special state rather than the normal default state.

I don't find that with bash; I have to explicitly fix it after
running a script that changes the terminal settings. I usually have
an exit trap:

trap '[ -t 0 ] && stty sane; printf "$NA$cu_vis$mouse_off"' EXIT


--
Chris F.A. Johnson, author              <http://cfaj.freeshell.org>
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
===== My code in this post, if any, assumes the POSIX locale
===== and is released under the GNU General Public Licence

[ Post a follow-up to this message ]

Barry Margolin wrote:
[...]
> I think most shells that provide real-time (e.g. emacs-style) input
> editing will reset the terminal state, because they require their own
> special state rather than the normal default state.

But why does installing a non-default signal handler make a difference,
then?

[ Post a follow-up to this message ]

richard.kreckel@framatome-anp.com writes:

> Barry Margolin wrote:
> [...] 
>
> But why does installing a non-default signal handler make a difference,
> then?

Could it be that the shell does the cleanup if the exit status of the
program indicates it was killed by a signal?

--
Måns Rullgård
mru@inprovide.com

[ Post a follow-up to this message ]