[BusyBox] RFC: giving respawn init actions a controlling tty?

[Allan Clark]

Erik;

I would prefer that busybox look at the <tty> in the configfile line to
see if a controlling tty is necessary, and if so, grab the tty as
needed.  Doing this implicitly allows for the existing config file
format, and provides the functionality that people seem to think is
already there... the assumed behavior might just be the intuitive one.

I mean, that's the way I use busybox init -- exactly as the sample
inittab shows in the documentation:

> tty2::askfirst:/bin/sh
> tty3::askfirst:/bin/sh
> tty4::askfirst:/bin/sh

I would recommend something that still permits this semi-intuitive
usage.

The presence of a "ttyX::respawn:" is really the same thing as saying
"::interactive-respawn:", right?  If we didn't want an interactive tty,
we'd not ask for one?

This also lets you avoid inventing "interactive-askfirst".

Allan



Erik Andersen wrote:
> 
> Currently the busybox init code assumes that "respawn" init
> actions are non-interactive, and therefore should not get a
> controlling tty.  This works fine when people use respawn to
> launch a getty or syslogd or some such thing.  However, we are
> increasingly seeing people try to launch ash, or bash, or minicom
> or midnight commander or some other interactive application.
> Since launching an interactive application using "respawn" does
> not provide a controlling tty, we then get people complaining
> that job control was disabled and similar problems.
> 
> I see two ways to solve this.  We can either give people a
> controlling tty for "respawn" init actions, or we can create a
> new type of init action, (i.e. "interactive-respawn") that does
> provide a controlling tty.  Thoughts?
> 
>  -Erik
> 
> --
> Erik B. Andersen             http://codepoet-consulting.com/
> --This message was written using 73% post-consumer electrons--
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/mailman/listinfo/busybox