I have an embedded board running Linux and with busybox as the shell.
I am upgrading the busybox to a higher version, but at the first time
I forget to compile the stty command in busybox, so the system is
booting without stty command. This time the /dev/tty can't be open
with error message of "can't turn on job control". The second time I
compiled the stty in busybox then the /dev/tty can works. But by
greping the /etc/ and /sbin/ directory, i can't find a script running
stty, so who runs stty and then affect the busybox behavior?

Another question is, when I start a command from shell, and press CTRL
+C, who will receive the SIGINT? Is it the shell first received the
signal and then forward to the running process or kernel send the
signal directly to the process? So the same for all the tty related
signals?

Thanks.

[ Post a follow-up to this message ]

On May 20, 4:55 pm, Bin Chen <binary.c...@gmail.com> wrote:
> I have an embedded board running Linux and with busybox as the shell.
> I am upgrading the busybox to a higher version, but at the first time
> I forget to compile the stty command in busybox, so the system is
> booting without stty command. This time the /dev/tty can't be open
> with error message of "can't turn on job control". The second time I
> compiled the stty in busybox then the /dev/tty can works. But by
> greping the /etc/ and /sbin/ directory, i can't find a script running
> stty, so who runs stty and then affect the busybox behavior?
>
> Another question is, when I start a command from shell, and press CTRL
> +C, who will receive the SIGINT? Is it the shell first received the
> signal and then forward to the running process or kernel send the
> signal directly to the process? So the same for all the tty related
> signals?
>
> Thanks.

First part... No idea... I am new to UNIX.
Second part..... When Kernel sends the signal, the sub-process(in any
depth) receives the signal  and the status of child (if not caught) is
again signaled to parent (i.e. shell here).

PS : Regarding shell scripts, if you run 2 command in a shell script
and hit ctrl+c when first is still running, only first command will
exit and the shell continues to run second command without itself
exiting.

Bye

[ Post a follow-up to this message ]

2007-05-20, 04:55(-07), Bin Chen:
> I have an embedded board running Linux and with busybox as the shell.
> I am upgrading the busybox to a higher version, but at the first time
> I forget to compile the stty command in busybox, so the system is
> booting without stty command. This time the /dev/tty can't be open
> with error message of "can't turn on job control". The second time I
> compiled the stty in busybox then the /dev/tty can works. But by
> greping the /etc/ and /sbin/ directory, i can't find a script running
> stty, so who runs stty and then affect the busybox behavior?

stty is a command line interface to the tcsetattr functio
(which is a wrapper to some tty ioctl on Linux). Many commands
(including the shell, vi...) will call that tcsetattr function
directly, they don't need stty.

The fact that you can't open /dev/tty or that job control
doesn't work is more probably due to the fact that the shell
doesn't have a controlling terminal. stty can't do anything
about that. This may happen if you're trying to run it on
/dev/console (as when booting Linux with init=/bin/sh). Instead,
you should have a line in /etc/inittab that runs some getty
command on /dev/ttyS0 or whatever your serial interface is (for
a serial console) and remove the init=...

> Another question is, when I start a command from shell, and press CTRL
> +C, who will receive the SIGINT? Is it the shell first received the
> signal and then forward to the running process or kernel send the
> signal directly to the process? So the same for all the tty related
> signals?
[...]

The foreground process group of the terminal will get it. The
shell, at its prompt will be in that group. When you run a
command in foreground (without &), the shell will create a new
process group and make it the foreground process group of that
terminal. When you hit Ctrl-C, that process group, that is the
command and every process it spawns, will get the SIGINT.

When using &, the shell starts a new process group but doesn't
make it the foreground process group. So, it won't get the
SIGINT, but it will get a SIGTTIN for instance if any of its
processes tries to read from the terminal.

See

info -f libc -n 'Job Control'

for more details.

--
Stéphane

[ Post a follow-up to this message ]

2007-05-20, 10:47(-07), guru:
[...]
> First part... No idea... I am new to UNIX.
>  Second part..... When Kernel sends the signal, the sub-process(in any
> depth) receives the signal  and the status of child (if not caught) is
> again signaled to parent (i.e. shell here).

The kernel sends the signal to every process in the foreground
process group of the terminal (set by the shell by a call to
tcsetprp).

>   PS : Regarding shell scripts, if you run 2 command in a shell script
> and hit ctrl+c when first is still running, only first command will
> exit and the shell continues to run second command without itself
> exiting.
[...]

Only if you installed a signal handler in the script with the
trap command. If you hit CTRL-C, the shell will get the signal
as well, so will be killed all the same.

Now, the behavior varies slightly from shell to shell. Some like
ash or pdksh based shells will block the signal until the
currently run command returns. That is, normally that command
will die and then the shell will die afterwards.

Some like zsh or ksh93 don't. So the shell will die immediately.
(the command may keep running in background if it ignores SIGINT
for instance).

bash has a very peculiar behavior. It block the signal as ash or
pdksh but seems to only die if the current command was killed.
So in bash -c 'cmd1; cmd2', if you press <Ctrl-C> while cmd1 is
running, cmd2 will be executed if cmd1 has a handler on SIGINT!
That looks like a bug or at best a misfeature to me.

--
Stéphane

[ Post a follow-up to this message ]