CLI tools should emit only ASCII unless instructed to do otherwise (e.g. cat'ing a UTF-8 encoded file)

Fun fact: you can show a progress bar using only ASCII. But only do it if stdout/stderr isatty please

n | █==== | 20%
e | ██=== | 40%
v | ███== | 60%
e | ████= | 80%
r | █████ | 100%

Another fun fact is that your output can be coloured but so can be the background of someone's terminal. I think there is a way to check what the bg is (termcap?), but generally colour being opt in, or at least opt out is a good idea. So many programs just don't bother and hardcode colours.

@sir Or you have a locate set that needs non-ascii.

I'm a bit torn on this. I think it's OK if LC_CTYPE indicates a Unicode-capable encoding.

The big offender is software that outputs colour escape sequences without checking if the terminal supports them.

@sir Can you explain to me why? I thought UTF-8 would be better because it covers more characters (I am talking about language based characters and not emojis)

I agree that ascii should definitely be the default, but I think we need to push more towards supporting UTF-8 as an option for output that can be easily selected or detected through environment variables.

I don't think that ascii should be the default forever.

Thats why we need an alternative to the VT200 standard.

Sign in to participate in the conversation
Mastodon is a private Mastodon instance for friends of SirCmpwn.