I've read and re-read about all those many quirks a lot of times over the decades, and some of the things I understand to an extend where I know what the issue is when something breaks... but man, the interactions between tty/pty, terminal (emulator), shell, screen, ssh and locales still sometimes make me want to scream.
Nothing better than sshing into a random system and getting a ~ when you hit backspace.
I used to think the unix way of doing this was overly baroque, till I had to figure out how a terminal emulator worked in Windows, which requires an actual instance of the windows default terminal program (con.exe I think?) be drawn on the screen. So if you want to grab the IO from a terminal program (say to make your own terminal emulator), the standard solution is to draw a windows terminal off the boundry of your monitor somewhere and scrape the text out and send it to your program.*
*(I think this situation has improved somewhat in recent years with Windows Console?, but I haven't had a chance to play with that yet).
I regularly re-read this article myself and refer new Linux devs on our team to it. It's pretty incredible that the system of PID/SID/PGID has survived under the hood of Linux (and Unix) for this many decades.
When the various discussions were years apart, like here, I suspect it would elide too much context to coalesce them.
But for submissions of the same vintage, it might be a good idea, and in fact not so different than the thread merging we already (but unsystematically) do.
When pasting HN link lists like this, it's extra considerate to include the dates and comment counts, since sometimes stories have little or no discussion.
Clicking through the links blindly wastes human time, especially for a longer list such as your post.
1. Generally speaking, dates are useful, but this is a link to article from 2008, so I'm not sure if previous submissions dates would be all that useful.
2. All links are to previous _discussions_, none are to discussion-less submissions.
Basically, the TTY driver keeps track of the foreground process group id, but only in a passive way. A user process can affect the behavior of any TTY device by manipulating the corresponding device file under /dev. For example, a user process can send a signal to the TTY driver, which will then suspend the process. TTY driver keeps track of the size of the connected terminal, but this information has to be updated explicitly, by the terminal emulator or even by the user. The TTY driver is a passive object.
For anyone new to the topic; don't panic at the size of the vertical scrollbar in the article - the majority of it is comments! The article itself is succinct and not a huge read.
SIGSTOP and SIGCONT are also really useful with GUI apps. I use them when I want to pause a major app like Firefox but don't want to sleep the entire machine.
Nothing better than sshing into a random system and getting a ~ when you hit backspace.