gemini://thrig.me/blog/2023/02/09/weird-terminal-things-SIGINFO.gmi

The INFO signal exists to, uh, it's a "status request from keyboard" according to the fine documentation in signal(3). A few tools actually implement support for SIGINFO, dd(1) for one,

> If dd receives a SIGINFO (see the "status" argument for stty(1)) signal, the current input and output block counts will be written to the standard error output in the same format as the standard completion message.

though many other tools instead print nothing--"no news is good news"--or spam the terminal with too much output. Some tools minimize their output to the terminal, but have a huge logfile somewhere for when things go awry, e.g. cpanm:

$ cd $ cpanm Compress::Zlib --> Working on Compress::Zlib Fetching http://www.cpan.org/authors/id/P/PM/PMQS/IO-Compress-2.204.tar.gz ... OK Configuring IO-Compress-2.204 ... OK ==> Found dependencies: Compress::Raw::Bzip2, Compress::Raw::Zlib --> Working on Compress::Raw::Bzip2 Fetching http://www.cpan.org/authors/id/P/PM/PMQS/Compress-Raw-Bzip2-2.204.tar.gz ... OK Configuring Compress-Raw-Bzip2-2.204 ... OK Building and testing Compress-Raw-Bzip2-2.204 ... OK Successfully installed Compress-Raw-Bzip2-2.204 (upgraded from 2.201) --> Working on Compress::Raw::Zlib Fetching http://www.cpan.org/authors/id/P/PM/PMQS/Compress-Raw-Zlib-2.204.tar.gz ... OK Configuring Compress-Raw-Zlib-2.204 ... OK Building and testing Compress-Raw-Zlib-2.204 ... OK Successfully installed Compress-Raw-Zlib-2.204 (upgraded from 2.202) Building and testing IO-Compress-2.204 ... OK Successfully installed IO-Compress-2.204 (upgraded from 2.201) 3 distributions installed $ wc -l .cpanm/build.log 9207 .cpanm/build.log

Two orders of magnitude reduction in terminal output is a pretty good.

Another option for tools that take copious amounts of time to run would be to support SIGINFO, like dd(1) does; this requires a SIGINFO handler that does something, either to print to the terminal or standard error some message, or to set a flag that indicates that a message should be made, if one is leery of doing too much work in a signal handler. For this example we can get away with doing too much work the signal handler.

$ perl -E '$SIG{INFO} = sub { say "boink!" }; sleep 1 while 1' ^T^T^T^T^T^C $ perl -E 'say $$; $SIG{INFO} = sub { say "boink!" }; sleep 1 while 1' 19252 ^Z[1] + Suspended perl -E "say \$\$; \$SIG{INFO} = sub { say \"bo $ kill -INFO 19252 $ fg perl -E "say \$\$; \$SIG{INFO} = sub { say \"bo boink! ^C

Well, that did not work. Via the terminal, anyways. The next piece of this puzzle is the "status" argument for stty(1), easy to miss in the dd(1) manual. It is unbound on OpenBSD by default.

Generally this gets bound to ^T, which stands for Tradition. You might be able to find a better reason why ^T is used.

$ stty -a | grep lnext erase = ^?; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; $ stty status ^T $ stty -a | grep status reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z;

For a literal ^T you need control+v control+t (unless someone changed what "lnext" is), or to emit the same with something like `printf '\024'`.

With status set we can boink! to our heart's content; presumably a real application would emit suitable progress information.

$ perl -E '$SIG{INFO} = sub { say "boink!" }; sleep 1 while 1' load: 0.45 cmd: perl 46440 [runnable] 0.00u 0.02s 0% 1087k boink! load: 0.45 cmd: perl 46440 [runnable] 0.00u 0.02s 0% 1089k boink! load: 0.45 cmd: perl 46440 [runnable] 0.00u 0.02s 0% 1089k boink! ^C

Here the key ^T is causing an INFO signal to be sent to the foreground process group as ksh(1) is also getting a piece of the action. The foreground process group thing also happens for ^C, a similar rat's nest of complexity.

Weird Terminal Things: SIGINFO