Rarely (but the cases exist and can all be found on modern Linux systems) I have also noticed that the coloring goes beyond recognition (e.g. Using different terminal emulators, shells or even options for the same terminal emulator, I have often received differently colored output. I have written quite a few scripts which just output raw ANSI sequences independently of TERM (usually with an option to turn that coloring on/off).
a pipeline may be entered interactively which will cause TERM to be set but color output to be (potentially) undesirable. Relying entirely on the environment's TERM variable can still be insufficient in these cases e.g. In these cases, it is often desirable to be able to obtain an output which is not colorized to simplify processing. an interactively used grep or scripted invication of the programs). If I understand the question correctly, it really boils down to opinion? The following tries to summarize some points worth considering Not all output is to terminalsĪs trivial as it sounds, even if every terminal on the world understands the ANSI sequences correctly (it is not the case as mentioned in the comments, for statements about all it is sufficient to find one counterexample to reject the statement): Consider the two cases of redirection to files or pipelining the output trough other programs (e.g. This works, and is a good solution in many cases, but in my opinion it introduces an unnecessary runtime cost, as it has to execute a separate binary multiple times right as my program starts.
#C LANGUAGE ANSI ESCAPE SEQUENCES SOFTWARE#
So, my question is: if I'm writing command-line software in 2019, is it safe to assume that it will only be used in terminals that speak ANSI?Įdit: People have proposed calling tput at runtime to print colours to the screen without having to deal with terminfo at all.
#C LANGUAGE ANSI ESCAPE SEQUENCES CODE#
It really seems like all other escape code sets have died out, and that ANSI codes (or ECMA-48 codes, or VT102 codes) have become the de-facto standard that the development community has settled on. And I very rarely see anybody complaining about this, or requesting support for other terminal types.įurthermore, I've seen many, many posts on the Internet that make no mention of any other terminal types or escape codes, referring to the ANSI set as "how to do bold and colours in a terminal".
I commonly see code that avoids using a helper library and just uses ANSI codes directly, or software that just checks if $TERM is anything other than dumb, or software that doesn't check $TERM at all. The pragmatist, on the other hand, has noticed that everybody has been embedding ANSI codes for years now, and everything seems to be fine.
My macOS installation comes with over two thousand terminal definitions in /usr/share/terminfo.
The idealist in me thinks that it's always better to rely on a standard than to rely on one particular implementation. However, I'm a lazy programmer, and if I want to make some text green, then by far the easiest thing to do is to embed ANSI escape codes directly in my program: print("\033[32mhi\033[0m")Ĭhanging the terminal colour this way is simple to implement, frees me from having to learn a new dependency (such as ncurses), frees me from running any external programs (such as tput), and lets me write my program in any language that has strings, rather than any language that has a terminal library. From what I know, a well-behaved command-line program should examine the $TERM environment variable get the name of the terminal emulator, look up its entry in the terminfo database, and then use those escape codes to control terminal settings such as colours, fonts, styles, erasing the screen, and setting the cursor position.
0 kommentar(er)
