[laumars]

Sadly that only removes 1 of the 3 methods of escaping terminal colours. Plus there is also the risk of it removing other SGR (Select Graphic Rendition) escape codes such as underline. That latter bug might be an acceptable casualty though.

[samatman]

It was meant to remove underline, bold, dim, and even blink.

Are there xterm codes for generating terminal color that don't end in m? It handily covers 8/88/256/24bit. What else is needed?

[laumars]

24bit uses the colon character as well. So if you're wanting to remove all SGR escape codes* then it's a pretty minor additional to your regex.

* Personally I quite like the bold and reset SGRs even when I don't want the term colourised. Bold can highlight text without drawing your attention away from the main body of the terminal.

[samatman]

I'm still looking for the use of ":" in xterm codes, but already discovered that this is a thing:

"\033]11;#53186f\007"

So, bare minimum, I'll need to include # in future. you can /generate/ 24 bit color using only ; and digits...

When filtering ANSI I'm usually streaming the result to something that expects pure ASCII, and tuning sed to only accept two escape codes would be a pain in the neck.

[laumars]

ISO 8613-6 uses colons. Admittedly it's a less supported standard.

Sadly handling terminal escape codes is one of those impossibly painful jobs. Heck, often even the terminals don't seem to support the escape codes they have documented or the documentation is so poor that you're basically left with trial and error (or a shit load of hex dumps to trawl through if you're lucky). eg I've wasted hours trying to get Kitty specific escape codes working on that terminal emulator before giving up.

I'm investing a lot of effort at the moment learning escape codes because I'm writing a new $SHELL which is designed to have rich media support even in $TERM's which don't support rich content. But I do still have support to convert the $SHELL back into a black and white console (I even have an option to strip colour from the STDOUT (even when pipelined) of all processes negating the need for your sed command. However that feature hasn't yet been committed back to the master branch.