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