On Sat, Jul 15, 2017 at 8:34 AM, Brandon Allbery <allber...@gmail.com> wrote:
> Ctrl-C sends SIGINT to all processes in the terminal's foreground process > group. There is no concept of "current process" on a terminal; Unixlike > systems are multitasking, and all processes in the process group have > access to the terminal, and there is no way for the OS to consider one of > them to be "the current process". (Indeed, it is possible, if unfortunate, > for multiple processes to be reading from the terminal at the same time.) > That only one such process can be considered by users to be "current" is > merely convention, and one that is easy to violate. > > (Shells make it more difficult by forcing command pipelines into separate > process groups, and controlling them by sending signals to the process > group; if running in the foreground, it will be assigned as the terminal's > current process group. If a process in such process group *not* in the > terminal's foreground process group tries to read from the terminal, it > gets SIGTTIN; if it tries to write, it gets SIGTTOU. If these are not > specifically handled by the process, they turn into SIGSTOP. This allows > shells to maintain the illusion that there is a "current process", provided > that only the first process in a pipeline reads from the terminal.) > If you want to find out about this in even more gory detail, you can look up the arguments about supporting SIGSTAT (Ctrl-T, as supported on *BSD and OS X) on Linux. It involves a number of gory hacks to maintain the pretense that there is a "current process", all of which are unreliable, fragile, and require quite a lot of ugliness in the kernel. AFAIK there's no convenient way to look up the terminal's foreground process group; you need to dig around in kernel memory to find the tty structure. "who -u" makes a guess though. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
