Question about init and controlling TTY

[Devin Bayer]

Hello.  When I was running some shells on the console recently I kept
getting the error message:

	-sh: no job control in this shell

This was even when using getty or the "-" prefix in the inittab.  So  
after
a little investigating I found that busybox/init/init.c opens the device
for each command without the O_NOCTTY flag.  The causes the first  
command
that's run on each terminal to control it.

In my case I wanted getty to respawn on the console and send output  
from the init
scripts there.  Since respawning actions happen later then once
actions, it doesn't seem possible with busybox init.

So I looked at the upstream sysvinit package.  It opens the terminal for
each command with the O_NOCTTY flag.  I think busybox should do the  
same.
Here is a patch:

Index: init/init.c
===================================================================
--- init/init.c (revision 14779)
+++ init/init.c (working copy)
@@ -430,7 +430,7 @@
                 setsid();

                 /* Open the new terminal device */
-               if ((device_open(a->terminal, O_RDWR)) < 0) {
+               if ((device_open(a->terminal, O_RDWR|O_NOCTTY)) < 0) {
                         if (stat(a->terminal, &sb) != 0) {
                                 message(LOG | CONSOLE, "device '%s'  
does not exist.", a->terminal);
                         } else {

Note that the "-" prefix for commands in busybox sets that command to
have the TTY controlling.  So without this patch,  
CONFIG_FEATURE_INIT_SCTTY
is pretty much useless, since it controls the tty anyway.  Was this
just an oversight?

-- 
Devin Bayer