4 ms·

The last process gets sigint and everything else gets sigpipe iirc

toast0 2y ago
That makes sense to me, but the article implied everything got a sigint, but the last program got it first. Eitherway, you'd need a different way to ask the shell to do it the otherway... Otoh, do programs routinely flush if they get SIGINFO? dd(1) on FreeBSD will output progress if you hit it with SIGINFO and continue it's work, which you can trigger with ctrl+T if you haven't set it differently. But that probably goes to the foreground process, so probably doesn't help. And, there's the whole thing where SIGINFO isn't POSIX and isn't really in Linux, so it's hard to use there... This article [1] says tcpdump will output the packet counts, so it might also flush buffers, I'll try to check and report a little later today. [1] https://freebsdfoundation.org/wp-content/uploads/2017/10/SIGINFO-Stay-in-the-Dark.pdf https://freebsdfoundation.org/wp-content/uploads/2017/10/SIG...
- toast0 2y ago
  > This article [1] says tcpdump will output the packet counts, so it might also flush buffers, I'll try to check and report a little later today. I checked, tcpdump doesn't seem to flush stdout on siginfo, and hitting ctrl+T doesn't deliver it a siginfo in the tcpdump | grep case anyway. Killing tcpdump with sigint does work: tcpdump's output is flushed and it closes, and then the grep finishes too, but there's not a button to hit for that.
tolciho 2y ago
No, INTR "generates a SIGINT signal which is sent to all processes in the foreground process group for which the terminal is the controlling terminal" (termios(4) on OpenBSD, other what passes for unix these days are similar), as complicated by what exactly is in the foreground process group (use tcgetpgrp(3) to determine that) and what signal masking or handlers those processes have (which can vary over the lifetime of a process, especially for a shell that does job control), or whether some process has disabled ISIG—the terminal being shared "global" state between one or more processes—in which case none of the prior may apply. $ make pa re ci cc -O2 -pipe -o pa pa.c cc -O2 -pipe -o re re.c cc -O2 -pipe -o ci ci.c $ ./pa | ./re | ./ci > /dev/null ^Cci (2) 66241 55611 55611 pa (2) 55611 55611 55611 re (2) 63366 55611 55611 So with "pa" program that prints "y" to stdout, and "re" and "ci" that are basically cat(1) except that these programs all print some diagnostic information and then exit when a SIGPIPE or SIGINT is received, here showing that (on OpenBSD, with ksh, at least) a SIGINT is sent to each process in the foreground process group (55611, also being logged is the getpgrp which is also 55611). $ kill -l | grep INT 2 INT Interrupt 18 TSTP Suspended

That makes sense to me, but the article implied everything got a sigint, but the last program got it first. Eitherway, you'd need a different way to ask the shell to do it the otherway... Otoh, do programs routinely flush if they get SIGINFO? dd(1) on FreeBSD will output progress if you hit it with SIGINFO and continue it's work, which you can trigger with ctrl+T if you haven't set it differently. But that probably goes to the foreground process, so probably doesn't help. And, there's the whole thing where SIGINFO isn't POSIX and isn't really in Linux, so it's hard to use there... This article [1] says tcpdump will output the packet counts, so it might also flush buffers, I'll try to check and report a little later today. [1] https://freebsdfoundation.org/wp-content/uploads/2017/10/SIGINFO-Stay-in-the-Dark.pdf https://freebsdfoundation.org/wp-content/uploads/2017/10/SIG...

toast0 2y ago
> This article [1] says tcpdump will output the packet counts, so it might also flush buffers, I'll try to check and report a little later today. I checked, tcpdump doesn't seem to flush stdout on siginfo, and hitting ctrl+T doesn't deliver it a siginfo in the tcpdump | grep case anyway. Killing tcpdump with sigint does work: tcpdump's output is flushed and it closes, and then the grep finishes too, but there's not a button to hit for that.

tolciho 2y ago

No, INTR "generates a SIGINT signal which is sent to all processes in the foreground process group for which the terminal is the controlling terminal" (termios(4) on OpenBSD, other what passes for unix these days are similar), as complicated by what exactly is in the foreground process group (use tcgetpgrp(3) to determine that) and what signal masking or handlers those processes have (which can vary over the lifetime of a process, especially for a shell that does job control), or whether some process has disabled ISIG—the terminal being shared "global" state between one or more processes—in which case none of the prior may apply. $ make pa re ci cc -O2 -pipe -o pa pa.c cc -O2 -pipe -o re re.c cc -O2 -pipe -o ci ci.c $ ./pa | ./re | ./ci > /dev/null ^Cci (2) 66241 55611 55611 pa (2) 55611 55611 55611 re (2) 63366 55611 55611 So with "pa" program that prints "y" to stdout, and "re" and "ci" that are basically cat(1) except that these programs all print some diagnostic information and then exit when a SIGPIPE or SIGINT is received, here showing that (on OpenBSD, with ksh, at least) a SIGINT is sent to each process in the foreground process group (55611, also being logged is the getpgrp which is also 55611). $ kill -l | grep INT 2 INT Interrupt 18 TSTP Suspended