I'd be happy if we could get terminals to agree on how wide the warning triangle emoji renders. The emoji are certainly useful for scripts, but often widths are such a crapshoot. I cannot add width detection to every bash script I write for every emoji I want to use.
If only there was a standards body that could perhaps spec how these work in terminals.
And shapes, though you can get that with some ASCII art as well.
I've had a few scripts some time ago that took a long time to run, so I wanted a progress indicator I could see from across the room - that way I could play some guitar while monitoring the computer doing stuff in the evening.
Hence, the log messages got prefixed with tags like:
> ]
>> ] # normal progress
/!\/!\] # it had to engage in a workaround
x_x ] # if it had to stop.
> Rendering [failed] in red and [passed] in green would achieve the same. It's not emoji vs text. It's color vs no color.
Thats only true for the terminal. When the same output is saved to a file or viewed via a non-terminal interface, the colors won't always be retained but the text/icons will be. E.g. in Jenkins console logs, you need to enable ASCII coloring explicitly to be able to see colored text.
> Rendering [failed] in red and [passed] in green would achieve the same. It's not emoji vs text. It's color vs no color.
True, but my prompt is full of colour ASCII characters so emoji stand out. And also, emoji fare better than escape codes when they pass through pipes and stuff.
And, frankly, why even bother with lower-case characters? Upper case is plenty good -- it was good enough for the VT05, it should be good enough for your laptop.
What a coincidence that I spent a good portion of time trying to deal with the warning triangle emoji and see your comment today. Incidentally the info and green ticks are not so bad. Wonder why that specific one has width issues.
You could ship a terminal with your script. This is how apps like Slack deal with inconsistent handling of standardized content by shipping an embedded chromium.
The ChromeOS terminal (hterm[1]) is actually a pretty good terminal, so even a terminal might justify a browser context. Blink[2] on iOS for example uses it.
[1]: https://hterm.org/ (although in the way they do Google seems to have lost interest in updating that site and the GitHub repo, there's still fixes in the upstream Chromium repo)
If only there was a standards body that could perhaps spec how these work in terminals.