A Terminal Protocol for Program Status (OSC 7501)

Innovations like this make me sad that terminfo seems to have died and/or quagmired. It makes detection of these features unscalable and/or impossible, because most of the neoterms are just lying in $TERM, and any value that wouldn't be a lie is missing data in terminfo.

I've also never really fully understood why terminfo seems to be a singular package, and not something like man pages where, e.g., each terminal drops in their respectively entry.

The BSDs have had a version of this for many, many years. If you hit ^T on the terminal, you deliver a SIGINFO to the application you're waiting for. By default, you get the program name, what its blocked on, and info about real/user/sys time and memory use.

Starting an emacs window in the fg:

% emacs ^T load: 0.32 cmd: emacs-31.1 64938 [select] 2.89r 0.75u 0.06s 6% 122404k

I just found out about this an hour ago while browsing the Pi docs. I'm really excited to use this as an alternative to the herdr pi extension as I prefer minimizing the number of extensions I have. Also, this could be great to use with a CI tracker (though I'd need one that works with Forgejo).

https://pi.dev/docs/latest/terminal-setup#program-status

I've been using a poor mans version of this for decades.

My iTerm2 is configured to show activity, new-output and visual bell in the tab. On Linux I have an approximation for WezTerm.

I have a bell command that I can use in a pipeline or sequence to produce the bell on events I'm interested in. Trivial case is when a program finishes.

I have a fancy alias that can be used in a shell command sequence and which produces different sounds depending on the exit status of the preceding command in addition to sending the terminal bell.

I second this. Herdr is too clunky but it’s the best we have right now.

Brings back to mind the old IBM 3270 terminal status line (everything old is new again :). Actually think this is quite a good idea.

I absolutely love this and hope it takes off. I've worked on several products with embedded terminals and reliably understanding when they were waiting for human input was such a pain.

The spec’s at https://www.superlogical.com/rex/docs/build/program-status

My first brush with CI, I ended up putting an option to play a sound at the end of local builds because I’d already noticed evidence of Hofstadter’s Law applying to build automation.

The thing is when you expect a task to take five minutes, you don’t watch it, you find something else you expect to take five minutes and do that instead. When that ends up taking ten minutes, or when you remember what you were doing before you started, you finally come back around ten minutes later to find that either the task completed four minutes ago, or it failed after ten seconds and you’ve wasted ten now.

The audio was the best out of band notification I had at my disposal 20 years ago.

My first thought when reading this was actually terminal multiplexing however, like screen or tmux. But I’m also always doing the terminal dance because I work on 4 FOSS projects and I keep 1+ terminal open per project so I can jump in and do bug fixes or pull PRs I’ve landed.

this would be cool to proxy into systemd's new systemd-appd metadata. https://www.phoronix.com/news/systemd-appd

[flagged]