A Terminal Protocol for Program Status (OSC 7501)

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 like the idea, but we already have the terminal bell. In my setup, when an agent is done or needs something, it emits a bell. Based on config, this results in a desktop notification if I’m not in the terminal, or a toast from my multiplexer if I’m in the terminal. The terminal pane gets a colored “bell” icon in its title that is cleared when I attach to it.

The total lack of mention of the terminal bell in the article is weird. I think it needs to be addressed for the protocol to be taken seriously. More granular info sounds nice, but also nice is the simplicity of the bell.

How does this compare to setting the status line on a terminal that supports one?

Cool to see this, I've been toying around with custom notification OSCs through zellij and ghostty.

Totally going to extend this for myself with a custom key that encodes a reverse route on each hop so I can easily jump to the window/tab/pane that emitted it, or send back custom actions into a given pane like a permission approve/deny.

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.

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 spec’s at https://www.superlogical.com/rex/docs/build/program-status

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 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.

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

There is another out-of-band way to handle this that a terminal host could implement (no OSC required)

- detect animation in the terminal (defined as changes without user input)

- when the animation stops it needs attention

- if it doesn't have the user's attention, ring some sort of bell

I built such a terminal specifically because this problem was driving me nuts. The marketing for it isn't finished yet (planning to launch next week) but it's been my daily-driver for months if you want to try it out: https://dormouse.sh/

But OSC 7501 seems like a great idea, I'll track its implementation here: https://github.com/diffplug/dormouse/issues/1079

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

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]