Wow, that's a sobering read. And comprehensive, and insightful. I hope this gets some attention and results in much needed improvements in that area.
this post was submitted on 31 May 2025
55 points (92.3% liked)
Linux
10931 readers
175 users here now
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
founded 2 years ago
MODERATORS
Oh, yeah. This doesn't surprise me. There's barely any nod to accessibility, and all of that's in desktop functionality. A braille terminal sounds like an utter nightmare, especially with more recent, "modern" tooling that insists on colorizing output, or self-managing paging. Libraries like Bubbletea make for some pretty output, but it's downright hostile for screen readers.
This is an old problem, too. I can't count the number of times I've furiously wasted time cleaning up output from a program that insisted on using terminal color codes. And I'm fully sighted.
Curious as to what those programs were. Most well-behaved programs can detect they're outputting to a pipe, for example, and will drop the terminal escape codes. That is, pushing the output through something like cat ought to have caused those codes to not be generated in the first place.
Those same programs often have an option to generate the codes regardless, but that shouldn't be the default.
An example here being the versions of ls that have the --color=auto option, which behaves the pipe-detecting way, and --color=force to send the escapes anyway. Of course, giving no --color option at all also avoids the escape codes, but many distros automatically set users up with an alias for ls that contains it, and the auto sub-option is precisely so users (and distro makers) can have ls act nicely.
Of course, the thing you were having trouble with might not have been a well-behaved program, which is why I'm curious.
Oh, most of the "old" programs are all well-behaved. It's just a crop of more recent tooling; I seem to encounter more frequently ones that either barf if they can't understand the terminfo, or always generate terminal codes that need to be cleaned out.
It's not just me. I think I have a shell function defined to strip control codes, but after trying to build it myself a while ago I ended up stealing someone else's that was more complete. The fact that it's easy to search for and find Q/A about this is a pretty good indication I'm not having a singular experience. IIRC, even the fairly complex perl script I eventually ended up with came with a disclaimer about there being edge cases it didn't handle.
My understanding of escape codes is that there's really only a handful (0x1bNNm) and they should be easy to strip, but there are complexities like being able to compound codes (0x1bNN;XXm) that make it more challenging. That's about where my knowledge ends.
I just know it's occasionally a PITA when I want to process data.
Oh! One example is immortal. immortalctl always dumps control characters and is impossible to reliably grep.
Sounds like a "pester the devs" kind of deal if it's an open-source project. It'd be a matter of them calling isatty(3) and a few extra if statements.
As for Perl, s/\e\[[0-9;]*[a-z]//gi would be my first attempt to get rid of them. You've probably been through all this already though.
Technical waffle:
The aforementioned regex/substitution would also delete malformed things like \e[;;;q, but since the offending supplier of codes is probably only generating valid codes, that shouldn't matter much. There are also rarer escape sequences that it doesn't catch, which would be where those better third party tools come in.
Come to think of it, there'd be a regex that detects everything laid out in the control_codes(4) man page (and, importantly, nothing that isn't). It would be one of those terrifying write-only things like the one that validates the full e-mail address standard, but that only proves that such things are possible.
I'm almost tempted to have a go at creating it. Almost. Maybe another day.
But here’s where Debian gets tripped up by the ecosystem: the moment you hit a login prompt, you enter a session with user-locked audio. This isn’t Debian’s fault. It’s the fault of PulseAudio, PipeWire, and the entire philosophy of session-bound audio daemons that don’t care what the kernel is doing.
It's worth noting that PipeWire is being developed with support for a system-wide, multi-user instance, which should solve the problem that I think the author is describing above. When I last checked a couple years ago, it was enabled with this build option: -Dsystemd-system-service=enabled
The name of that flag seems to imply that systemd is required, which would be disappointing for folks who use other init systems. I haven't tried it, so I don't know if it's a true requirement or just a name that was convenient at the time it was created.
But here’s where Debian gets tripped up by the ecosystem: the moment you hit a login prompt, you enter a session with user-locked audio. This isn’t Debian’s fault. It’s the fault of PulseAudio, PipeWire, and the entire philosophy of session-bound audio daemons that don’t care what the kernel is doing.
It always seemed sus to me that Debian of all distros would stop adding ALSA by default, tbh. And for the crap that was PA at the time, too!
To make things worse, Systemd assumes everyone is willing, able and compliant, but even using Linux in the first assumes at least the latest one is not always true.
Didn't lennart also do pulse-audio as well as his systemd cancer? I'd not be surprised to hear that one crutches on the other and excludes choice.