Re: bin/51556: less(1) generates SIGTTOU if lacking a controlling terminal

[mlelstv%serpens.de@localhost (Michael van Elst)]

The following reply was made to PR bin/51556; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/51556: less(1) generates SIGTTOU if lacking a controlling terminal
Date: Thu, 13 Oct 2016 05:10:38 +0000 (UTC)

 jschauma%netmeister.org@localhost (Jan Schaumann) writes:
 
 > 	if (setpgid(0, 0) == -1) {
 > 		fprintf(stderr, "Unable to setpgid: %s\n", strerror(errno));
 > 		exit(1);
 > 	}
 > 	no_tty = tcgetattr(fileno(stdout), &otty);
 > 	if (!no_tty) {
 > 		if (tcsetattr(fileno(stderr), TCSANOW, &otty) == -1) {
 > 			fprintf(stderr, "Unable to tcsetattr: %s\n", strerror(errno));
 > 			exit(1);
 > 		}
 > 	}
 
 > /bin/sh has the controlling terminal, but a.out does not.  tcsetattr(3)
 > here triggers SIGTTOU and suspends the process.  This is the behaviour I
 > observed in Debian's more(1), and I see similar behaviour in our
 > less(1), but I haven't been able to pinpoint the code triggering it.
 
 
 That's how UNIX does job control, it has little to do with more or less.
 
 The feature exists to prevent a _background process_ from interfering with
 the terminal. While output from a background process itself may or may not pass,
 changing the terminal settings is always stopped.
 
 Try to run less in the background to get the same behaviour.
 
 The only issue here is that UNIX job control is pretty limited and that timeout
 abuses the job control.
 
 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."