Hi -
I am using busybox-1.10.2 for our embedded application and noticed
something peculiar about how the shell behaves after the application
terminates. Specifically, I'm noticing that:
1. If there is no signal handler in the application, a <CNTRL>-C
will not only terminate the application, but it appears that it
propagates to the shell and kills not only the shell, but also the
telnet session that is hosting the shell, which results in a telnet
disconnect.
2. We have a simple little keyboard handler tied to this app that:
a. Turns echo off
b. Turns canonical mode off
c. Turns extended input processing off
d. Turns signal chars off
e. Make I/O non-blocking (G_IO_FLAG_NONBLOCK)
Essentially - buf.c_lflag &= ~(ECHO|ICANON|IEXTEN);
If the default KB/IO settings are not returned to their original state,
it seems as though these attributes are passed from the application back
to the shell (ash), which then messes with the next app that is started
from the shell. For example, if you start up 'vi' right after the
previous app terminates, you will see the following msg in 'vi':
last_cmd_overrun
This mesg just repeats over and over again and 'vi' is completely
unusable at this point. It will not be able to take any more key input.
I was wondering if there is a setting for ash that prevents applications
that are fork'ed and exec'ed from ash from messing with the terminal
settings? It seem as though the shell should be responsible for making
sure that everything is returned to a known good state after an
application exits and should not rely on the application for making sure
everything is returned properly.
Does anyone know anything about this phenomena?
Thanks,
Ben
Intel Corp
[EMAIL PROTECTED]
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
