Both calls will fail if we are already a process group leader, or the
process group leader is not us, or we already have a controlling terminal.
So basically these calls are harmless in the worst case, and get rid of the
annoying can't access tty; job control turned off problem in the best
case.
Would this have an effect on scripts being used as init which did not
previously have a controlling terminal? There are quite a few commands
which change behavior when run with/without a tty.
(the usual fix for enabling job control is to run agetty in your init
script)
-Mike
On 3/12/2012
On Mon, Mar 12, 2012 at 8:09 PM, Michael Conrad mcon...@intellitree.com wrote:
Would this have an effect on scripts being used as init which did not
previously have a controlling terminal? There are quite a few commands
which change behavior when run with/without a tty.
(the usual fix for
On Tuesday 13 March 2012 00:56, Avery Pennarun wrote:
Both calls will fail if we are already a process group leader, or the
process group leader is not us, or we already have a controlling terminal.
So basically these calls are harmless in the worst case, and get rid of the
annoying can't
On Tuesday 13 March 2012 01:18, Avery Pennarun wrote:
On Mon, Mar 12, 2012 at 8:09 PM, Michael Conrad mcon...@intellitree.com
wrote:
Would this have an effect on scripts being used as init which did not
previously have a controlling terminal? There are quite a few commands
which change
On Mon, Mar 12, 2012 at 11:16 PM, Denys Vlasenko
vda.li...@googlemail.com wrote:
This makes busybox sh job control usable with init=/bin/sh on the Linux
kernel command line.
I don't think so. In this case, stdio is redirected to /dev/console.
In Linux, /dev/console can't be a controlling
