On 8/29/24 4:59 PM, Martin D Kealey wrote:

On Fri, 30 Aug 2024 at 04:17, Robert Elz <k...@munnari.oz.au <mailto:k...@munnari.oz.au>> wrote:

    SIGTTOU is also sent, unconditionally, by any attempt to change any of
    the terminal's attributes, and the process (group) (by default) stops.
    (I don't recall off hand whether simply fetching the attributes is
    enough to generate SIGTTOU.)   Just as there's no stty option to avoid
    SIGTTIN (reading from the terminal) there's no option to avoid this
    kind of SIGTTOU - or there shouldn't be.


I've encountered something related to this, where the shell takes charge of the terminal, away from another process that is using it.

This happens when trying to debug a modified version of Bash, with "gdb ./ bash" then "run". Gdb then stops twice before Bash prints its prompt, even though Bash doesn't (seem to) print or read anything.

Most likely, bash can't make itself a process group leader to perform job
control. It will try a number of times, then give up and turn job control
off. Since gdb catches all signals sent to the target process, it reacts.
Look at jobs.c:initialize_job_control().

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    c...@case.edu    http://tiswww.cwru.edu/~chet/

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to