Something that reads 'ASCII byte range > 0x7f' in the second paragraph of its syntax description has not started well. ASCII has no codes above DEL, and allowing the C1 controls is useless and actually leads to problems of command sequences and control sequences inside command strings, since CSI, SOS, and the like are C1 controls.
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.
What’s the difference? SIGINFO asks the program what it’s doing and displays it. Anyone is welcome to put a layer on top of that which polls (with SIGINFO) in the background and displays any changes.
As long as the signal is built, like any good interrupt code, to only do message passing instead of blocking work then there won’t be any performance issues. We’re polling between a handful of local processes that are in the order of human-computer interaction, not polling remotely in a large scale way.
This is important (and TIL OSC 3008, how do we all keep up?!), but I want something adjacent to this... perhaps people can point me in a direction.
This OSC 7501 pushes state from Program to Terminal; with an explicit running/idle/fubar "state" field but also K/V data. Then Terminal can provide interactions thereof, such as display it.
What I want is for the Program to push the terminal some map of "key:command" which is available for the terminal to provide interactions thereof. Maybe that can come through just as a key in this?
Here's the motivation: when using a TUI on a phone or tablet, the keyboarding experience is horrible (unless you have a physical keyboard). It takes up too much real estate and most of the time there's only three keys action you want to hit.
An obvious solution is to put up HTML buttons and other chrome for users to tap. Personally, I've handled that bespoke at the library+application level, where the Golang and HTML+JS container work together. There's some reusability because it can just take a BubbleTea Help Model (holds keybindings), but it is limited.
In the last few weeks, I've started seeing Claude do this unasked for me (creating parallel Web/TUI interfaces), but it was actually building more complicated Web scaffolding, rather than it being deterministically rendered from a specification by the harness.
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.
The terminall bell is just the representation of ascii for 7 (decimal) or Ctrl+G. I believe all terminal do support it, although most emulators allows to make it a visual effect instead of a sound. And they usually send a notification to the desktop environment or windows manager.
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.
As a frequent internal tool writer, I’d say it’s a fact of life but an undesirable one. I’m always trying to avoid pausing for credentials in the middle of a run, either by doing them right at the beginning or by using some sort of durable credentials system like ssh keys.
There’s always two people at every company who refuse to set up auth automation though, so you end up handling it. They are very stubborn. Even when it trips them up in front of observers while executing an urgent task, I’ve only occasionally convinced them to agree to set up trust instead of typing a password every single time.
Which is to say, I have to support password prompts even though they drive me up the wall.
Let's say I'm upgrading a large software enterprise application.
I start the upgrade process.
After 5 minutes, the process determines that the upgrade will require an extra 1.5GB of storage and asks me if I would like to continue with the upgrade.
After 15 minutes, I'm presented with a username / password prompt to enter credentials to retrieve a package from an external resource needed for the upgrade.
After another 5 minutes, the upgrade process has detected that there are a number of derelict files detected and asks for permission to remove these files.
It's a product of the scope limited interface granted to agents. They get a terminal stream so everything goes into the stream. Piling on more in-band signaling is just going to become a security nightmare. It would be better to have a safe way to query process state that can be locked down as needed.
As someone who works on a lot of CLI tools at work I actually like the idea of implementing this in some of our long-running tooling, completely independent of the AI agent use case.
The original idea I had being that CI environments, or anywhere that shows terminal output, could use a streaming ANSI parsing library to detect when a program sent a 'change window title' OSC event and then start a new collapsable section in its output. This would let programs update the actual terminal window title with its current state when running locally and update the CI interface when running in CI.
Adding in the ability to specify the program's current status and (optionally) progress could be extremely useful in CI environments as well. Imagine, for example, a long-running analysis task which uses OSC 7501 to say that it's currently running and is 75% of the way done. CI could expose that in the UI to provide useful information to the end-user without having to print a progress bar or multiple progress lines to the fake terminal it's being run in.
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.
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).
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.
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.
I'm starting to lean in the opposite direction and feel like we should have probably stopped at ecma-48. piling up extension after extension is just straying further from the light.
I don't see how terminfo matters for this protocol. An app can emit the escape sequences unconditionally, and if the terminal doesn't support it, it will ignore them. Graceful degradation at its best.
That’s not how terminals actually work, at least if you’re talking about actual serial terminals. They often do not gracefully degrade and this kind of “everyone is using a window with the latest fancy thing” needlessly excludes people who might like to use them.
That abstract state diagram is not, as eschaton said, how terminals actually work.
And it isn't just real terminals. Several terminal emulators are bad at handling syntactically valid but unknown to the emulator control strings. There are several whose authors hadn't read ECMA-35 and ECMA-48, and based their programs on samizdat lists of control sequences circulating years ago, without realizing that there was a full consistent syntax underlying them. Unrecognized control sequences are sometimes just printed as text, or worse.
Indeed, OSC itself is notorious for being such a case, where for a time some emulators expected BEL instead of ST as the string terminator.
> Correctness – if you were to feed this parser a stream of characters that is random or deliberately pathological, it is claimed that this parser will exhibit the same visible behaviour as any one of DEC’s 8-bit ANSI-compatible terminals, from VT220 to VT525. A VT100-series parser would be simpler still, as the VT100 only supports 7-bit characters.
To your other point, if we're not talking about replacing expensive hardware anymore, but just obscure buggy software--shouldn't they fix the bugs instead of the entire industry halting all forward progress for the rest of time?
We've done this before. Hyperlinks are a pretty recent introduction, and are widespread by now. So either these buggy terminal emulators were already fixed as hyperlink usage became widespread, or they're unmaintained and already broken by hyperlinks. Either way, new standards won't make the situation any worse.
terminfo has not died. M. Dickey made updates to it last month.
terminfo's problem is that it is really difficult to make changes that extend or do not fit the original paradigm, not least because the actual database format does things like have a fixed set of implicitly-named boolean capabilities, with any additional capabilities having to be named 'extensions'.
But other problems include terminfo's model of how things work, such as function keys for example, not really matching how they actually work in terminals and terminal emulators. For function keys, for example, DEC terminals allowed modifier state to be sent in parameters to DECFNK. terminfo's design had no concept of this.
How hard do you think it would be to rewrite a large subset of userspace tools to codesign with a completely new terminal protocol? I feel like in the age of personal computing, this should be possible and would be nice if it were possible.
Nushell already kind of has this philosophy - there is a separation between the actually scripting of tools (prints out structured json), and the visualization back to the user if it's a terminal. On top of this, you could say, have some awareness of, "If I know I'm the remote, I can pass a json list to the userdirectly and have them render client-side, rather than pretend to be a terminal".
It may be inefficient for some cases, but then you could actually say, execute the vision of mosh.
The terminal, in the abstract, is one of the best abstractions ever. The implementation is tied down to 1980s tech.
You could always spin up a "normal" terminal if you're ssh'd into some remote server to do sysadmin stuff. IMO you shouldn't be installing personal configs on there anyways (maybe allow a copy pasted .bashrc and .tmux.conf)
Another thing you could do - neovim already has neovide, you could make this native, right? You would maybe write an adapter for neovim on the remote (again, all of this is in vresion control + nix; this is how I use dotfiles; and at work I'm doing nothing fancy since I don't have control over host, it's just temrinal integration) - if I type "nvim" in the "shell" application, it actually opens up its msgpack GUI protocol.
Maybe at some point you're just re-inventing emacs though.
The distinction between those semantics died a long time ago by others I'm sorry to say, and I'm continuing to persist that.
APC is far less supported overall by terminals (for example, Terminal.app on macOS would simply dump APC to the screen, ignore the framing, and treat the APC data as normal pty data, and Terminal.app is used by a LOT of people). Plus, its anything-goes format makes it hard to ship safe protocols that overlap with others (APC was always meant afaik for _one_ protocol -- the application's, not multiplexing many).
Compare this to OSC which is well supported, has a well defined multiplexing format (the first number), and has a well defined framing that all terminals I know of ignore for unknown values. That's perfect.
As the Arcan project so eloquently stated[1]: "Terminal emulators emulate a machine that has never existed, a fantasy computer." More details in the link by people I respect who have worked on this problem far longer than I have.
Operating System Command actually doesn't have a well defined multiplexing format. That 'first number' is not in the standards. It's a thing that has haphazardly grown as people have tacked more and more stuff onto OSC. The standards don't even guarantee numbers in the command string at all.
In fact, you can say the exact same thing about OSC (it was meant for one protocol, the operating system's) as you just did about APC. Because that's what ECMA-48 actually says: 'The interpretation of the command string depends on the relevant operating system.'
There is no operating system standard for this in the Unices or in Linux-based operating systems. As I said, this is something that haphazardly grew in the last decade or so as people decided that they needed some kind of terminal control string, and how dtterm and xterm had been processing OSC (very limited compared to all of the things that people have nowadays tacked on) was there.
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/
The problem `OSC 7501` addresses would slot almost perfectly into [UAPI.15 OSC 3008](https://uapi-group.org/specifications/specs/osc_context/#met...).
It's already implemented by `systemd` and is available in Ubuntu 26.04.
I'd rather see `OSC 3008` being extended.
There’s already a thread with mitchellh about this on X
https://x.com/mitchellh/status/2108316851537322111?__frodo=r...
Alternative version:
https://nitter.click/mitchellh/status/2108316851537322111?__...
Or its specification fixed.
Something that reads 'ASCII byte range > 0x7f' in the second paragraph of its syntax description has not started well. ASCII has no codes above DEL, and allowing the C1 controls is useless and actually leads to problems of command sequences and control sequences inside command strings, since CSI, SOS, and the like are C1 controls.
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
Darwin also supports it
Darwin is a BSD.
Not exactly tho, Darwin is a BSD derivative
Technically true but not informative
It would be much better if we adopted SIGINFO + env variable where to respond.
This way, anyone who needs AI agent status can just send SIGINFO signal and wait for the response.
Could this be a Pull vs Push issue?
^T is a Pull
OSC7591 is a Push
What’s the difference? SIGINFO asks the program what it’s doing and displays it. Anyone is welcome to put a layer on top of that which polls (with SIGINFO) in the background and displays any changes.
As long as the signal is built, like any good interrupt code, to only do message passing instead of blocking work then there won’t be any performance issues. We’re polling between a handful of local processes that are in the order of human-computer interaction, not polling remotely in a large scale way.
This is important (and TIL OSC 3008, how do we all keep up?!), but I want something adjacent to this... perhaps people can point me in a direction.
This OSC 7501 pushes state from Program to Terminal; with an explicit running/idle/fubar "state" field but also K/V data. Then Terminal can provide interactions thereof, such as display it.
What I want is for the Program to push the terminal some map of "key:command" which is available for the terminal to provide interactions thereof. Maybe that can come through just as a key in this?
Here's the motivation: when using a TUI on a phone or tablet, the keyboarding experience is horrible (unless you have a physical keyboard). It takes up too much real estate and most of the time there's only three keys action you want to hit.
An obvious solution is to put up HTML buttons and other chrome for users to tap. Personally, I've handled that bespoke at the library+application level, where the Golang and HTML+JS container work together. There's some reusability because it can just take a BubbleTea Help Model (holds keybindings), but it is limited.
In the last few weeks, I've started seeing Claude do this unasked for me (creating parallel Web/TUI interfaces), but it was actually building more complicated Web scaffolding, rather than it being deterministically rendered from a specification by the harness.
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.
Did you read the section on "Relationship to other sequences?"
https://www.superlogical.com/rex/docs/build/program-status#r...
Also - definitely a mention of the terminal bell on https://www.superlogical.com/rex/docs/automate/shell-scripti...
The terminall bell is just the representation of ascii for 7 (decimal) or Ctrl+G. I believe all terminal do support it, although most emulators allows to make it a visual effect instead of a sound. And they usually send a notification to the desktop environment or windows manager.
Wuff, Wuff!!
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.
The spec’s at https://www.superlogical.com/rex/docs/build/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.
Brings back to mind the old IBM 3270 terminal status line (everything old is new again :). Actually think this is quite a good idea.
> Actually think this is quite a good idea.
That's what I thought in the beginning. Once I read the spec to the end, it's clear to me that it's overly specific to one use-case — TUI AI agents.
E.g. `kind := permission | question | auth` doesn't make much sense anywhere outside of that use case. The list goes on...
I also found comms around it super muddy, AI agent use case is mentioned but deceivingly watered down with other use-cases.
Overall, that spec is no where close to Kitty/Kovid's level. It's super sad, since mitchellh's work is usually super high quality.
I hope the community will push back and the spec will get better.
A cli asking for a password is a pretty normal thing, I think?
As a frequent internal tool writer, I’d say it’s a fact of life but an undesirable one. I’m always trying to avoid pausing for credentials in the middle of a run, either by doing them right at the beginning or by using some sort of durable credentials system like ssh keys.
There’s always two people at every company who refuse to set up auth automation though, so you end up handling it. They are very stubborn. Even when it trips them up in front of observers while executing an urgent task, I’ve only occasionally convinced them to agree to set up trust instead of typing a password every single time.
Which is to say, I have to support password prompts even though they drive me up the wall.
Yes, but a CLI can ask for literally anything. We'll end up adding things there and with a zoo of hard-to-support implementation of that _protocol_.
CLI can also _blank_, do we want to support it as well?
Let's say I'm upgrading a large software enterprise application. I start the upgrade process. After 5 minutes, the process determines that the upgrade will require an extra 1.5GB of storage and asks me if I would like to continue with the upgrade. After 15 minutes, I'm presented with a username / password prompt to enter credentials to retrieve a package from an external resource needed for the upgrade. After another 5 minutes, the upgrade process has detected that there are a number of derelict files detected and asks for permission to remove these files.
Isn’t that why the bell is for?
It's a product of the scope limited interface granted to agents. They get a terminal stream so everything goes into the stream. Piling on more in-band signaling is just going to become a security nightmare. It would be better to have a safe way to query process state that can be locked down as needed.
As someone who works on a lot of CLI tools at work I actually like the idea of implementing this in some of our long-running tooling, completely independent of the AI agent use case.
I actually created a separate golang library with something like this in mind: https://github.com/danudey/ansipants
The original idea I had being that CI environments, or anywhere that shows terminal output, could use a streaming ANSI parsing library to detect when a program sent a 'change window title' OSC event and then start a new collapsable section in its output. This would let programs update the actual terminal window title with its current state when running locally and update the CI interface when running in CI.
Adding in the ability to specify the program's current status and (optionally) progress could be extremely useful in CI environments as well. Imagine, for example, a long-running analysis task which uses OSC 7501 to say that it's currently running and is 75% of the way done. CI could expose that in the UI to provide useful information to the end-user without having to print a progress bar or multiple progress lines to the fake terminal it's being run in.
long-running analysis task can use osc9;4 for progress reporting
spec: https://ghostty.org/docs/vt/osc/conemu
Is https://github.com/danudey/ansipants private?
The “progress” should include an estimate of total time or time remaining.
For example, dd or rsync would be quite simple to enable with this.
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.
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
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.
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.
I'm starting to lean in the opposite direction and feel like we should have probably stopped at ecma-48. piling up extension after extension is just straying further from the light.
I don't see how terminfo matters for this protocol. An app can emit the escape sequences unconditionally, and if the terminal doesn't support it, it will ignore them. Graceful degradation at its best.
That’s not how terminals actually work, at least if you’re talking about actual serial terminals. They often do not gracefully degrade and this kind of “everyone is using a window with the latest fancy thing” needlessly excludes people who might like to use them.
Even some physical terminals from 50 years ago gracefully ignored unknown escape sequences.
https://vt100.net/emu/dec_ansi_parser
Just look how many paths lead to the "csi ignore" state.
Do you have a specific physical terminal that's even older than the VT100 that you're worried about?
That abstract state diagram is not, as eschaton said, how terminals actually work.
And it isn't just real terminals. Several terminal emulators are bad at handling syntactically valid but unknown to the emulator control strings. There are several whose authors hadn't read ECMA-35 and ECMA-48, and based their programs on samizdat lists of control sequences circulating years ago, without realizing that there was a full consistent syntax underlying them. Unrecognized control sequences are sometimes just printed as text, or worse.
Indeed, OSC itself is notorious for being such a case, where for a time some emulators expected BEL instead of ST as the string terminator.
From the site:
> Correctness – if you were to feed this parser a stream of characters that is random or deliberately pathological, it is claimed that this parser will exhibit the same visible behaviour as any one of DEC’s 8-bit ANSI-compatible terminals, from VT220 to VT525. A VT100-series parser would be simpler still, as the VT100 only supports 7-bit characters.
To your other point, if we're not talking about replacing expensive hardware anymore, but just obscure buggy software--shouldn't they fix the bugs instead of the entire industry halting all forward progress for the rest of time?
We've done this before. Hyperlinks are a pretty recent introduction, and are widespread by now. So either these buggy terminal emulators were already fixed as hyperlink usage became widespread, or they're unmaintained and already broken by hyperlinks. Either way, new standards won't make the situation any worse.
terminfo has not died. M. Dickey made updates to it last month.
terminfo's problem is that it is really difficult to make changes that extend or do not fit the original paradigm, not least because the actual database format does things like have a fixed set of implicitly-named boolean capabilities, with any additional capabilities having to be named 'extensions'.
* https://github.com/mauke/unibilium/blob/master/secret/termin...
But other problems include terminfo's model of how things work, such as function keys for example, not really matching how they actually work in terminals and terminal emulators. For function keys, for example, DEC terminals allowed modifier state to be sent in parameters to DECFNK. terminfo's design had no concept of this.
How hard do you think it would be to rewrite a large subset of userspace tools to codesign with a completely new terminal protocol? I feel like in the age of personal computing, this should be possible and would be nice if it were possible.
Nushell already kind of has this philosophy - there is a separation between the actually scripting of tools (prints out structured json), and the visualization back to the user if it's a terminal. On top of this, you could say, have some awareness of, "If I know I'm the remote, I can pass a json list to the userdirectly and have them render client-side, rather than pretend to be a terminal".
It may be inefficient for some cases, but then you could actually say, execute the vision of mosh.
The terminal, in the abstract, is one of the best abstractions ever. The implementation is tied down to 1980s tech.
You could always spin up a "normal" terminal if you're ssh'd into some remote server to do sysadmin stuff. IMO you shouldn't be installing personal configs on there anyways (maybe allow a copy pasted .bashrc and .tmux.conf)
Another thing you could do - neovim already has neovide, you could make this native, right? You would maybe write an adapter for neovim on the remote (again, all of this is in vresion control + nix; this is how I use dotfiles; and at work I'm doing nothing fancy since I don't have control over host, it's just temrinal integration) - if I type "nvim" in the "shell" application, it actually opens up its msgpack GUI protocol.
Maybe at some point you're just re-inventing emacs though.
This is not really an Operating System Command at all, though. It is an Application Program Command (U+009F).
The distinction between those semantics died a long time ago by others I'm sorry to say, and I'm continuing to persist that.
APC is far less supported overall by terminals (for example, Terminal.app on macOS would simply dump APC to the screen, ignore the framing, and treat the APC data as normal pty data, and Terminal.app is used by a LOT of people). Plus, its anything-goes format makes it hard to ship safe protocols that overlap with others (APC was always meant afaik for _one_ protocol -- the application's, not multiplexing many).
Compare this to OSC which is well supported, has a well defined multiplexing format (the first number), and has a well defined framing that all terminals I know of ignore for unknown values. That's perfect.
As the Arcan project so eloquently stated[1]: "Terminal emulators emulate a machine that has never existed, a fantasy computer." More details in the link by people I respect who have worked on this problem far longer than I have.
[1]: https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
Operating System Command actually doesn't have a well defined multiplexing format. That 'first number' is not in the standards. It's a thing that has haphazardly grown as people have tacked more and more stuff onto OSC. The standards don't even guarantee numbers in the command string at all.
In fact, you can say the exact same thing about OSC (it was meant for one protocol, the operating system's) as you just did about APC. Because that's what ECMA-48 actually says: 'The interpretation of the command string depends on the relevant operating system.'
There is no operating system standard for this in the Unices or in Linux-based operating systems. As I said, this is something that haphazardly grew in the last decade or so as people decided that they needed some kind of terminal control string, and how dtterm and xterm had been processing OSC (very limited compared to all of the things that people have nowadays tacked on) was there.
How does this compare to setting the status line on a terminal that supports one?
I second this. Herdr is too clunky but it’s the best we have right now.
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
It's one of those 250 different ways to "measure" attention Mitchell mentioned in the blog post.
Super brittle.
https://xkcd.com/927/
this would be cool to proxy into systemd's new systemd-appd metadata. https://www.phoronix.com/news/systemd-appd