Hacker News Reader

Comment by withinboredom | Hacker News Reader

I can think of a number of things this tinting would break.

It violates the principle of Least Surprise; if I'm invoking run0 I'm expecting it to run my program with a different UID and return the same stdout I'd have gotten if I had just run the program in my shell. Not inject a whole bunch of color control bytes in there. Which hopefully my terminal will handle. Unless it doesn't.

I'll give them the benefit of the doubt and assume they only do this if $TERM supports color. But still. That $TERM variable can surprise a poor programmer in all sorts of ways.

Any sane command line program will only output color codes if isatty(STDOUT_FILENO) succeeds.

That can succeed in a number of cases, where it actually isn't a tty with a user on the other end of it. There are a number of internal tools at work that only output logging if there is a tty and thus are run in their cronjobs with a tty. If there were unexpected color outputs in the logs, that would suck since the log aggregators probably wouldn't know what to do with it.

But sudo already doesn’t do that either. Eg sudo may ask for a password, and output some control sequences which hide the text so your password is not visible.

This feels like much ado about nothing.

Edit: Also don’t forget the “with great power comes great responsibility” blurb that sudo likes to output. I know that doesn’t happen in scripts when output is redirected, but I’m sure run0 will figure that out too.

asking for a password to do an authenticated action is about as far away from surprising as I can legitimately reason about.

The contextual blurb does have a way of disabling it in a persistent config, which is easy enough to set. It also goes to stderr and not stdout and does nothing to alter the output of the command itself.

It also does not show if you have NOPASSWD: set in your sudoers. So even less surprising.

> sudo may ask for a password, and output some control sequences which hide the text so your password is not visible.

You can turn this off for certain users and/or programs.

Can you name any?

The user's choice of color schemes.

If the program you're running prints red text, then you get red bgcolor with red fgcolor. Good luck reading that.

(Also, users with the wrong color scheme get that experience by default. Though that is a niche use case enough that I'd be surprised if systemd devs cared about it.)

Containers run with a tty attached but no console on the other end and then trying to read the logs, for starters. Additionally, as mentioned, conflicts with the user's color scheme or even the program's. Further, it's possible to do this without the help of run0, so I suspect users already doing that are going to get their colors messed up and be annoyed. For example, prod machines are usually red, and running as root on a prod machine is royal purple. If this is used, seeing a red background instead of a purple one is likely non-desirable.

XMODEM and the like expect the terminal stream to not have garbage added by e.g. run0.

The terminal line should be clean between XMODEM at the terminal emulator and at the client end.

Is xmodem still used outside of computer museums (including private computer museums)?

It's e.g. still very popular with embedded development. One example: u-boot supports it.

It is the easiest way to upload an image to u-boot, as it does use the same terminal, thus there is no need to set up a secondary path; If you can talk with the u-boot CLI, you can also upload with xmodem.

Reply on news.ycombinator.com