terraform needs a way to obviate color everywhere, globally, at once

[pixleyr]

The color output makes the output illegible to many people. There needs to be a way to turn it off globally.

I'm aware of the -no-color option on some commands but that's insufficient. I forget. It's too long. it only works on some commands.

I'm also aware of TERM, but I don't want TERM broken. I still use TERM for my curses based apps like vi, emacs, etc.

I just want a way to be able to read the output from terraform.

[pselle]

Hello @pixleyr! Would using an environment variable work for your use case, and if not, for which use cases does it not? You mentioned that -no-color doesn't work on all commands, so which ones are you still seeing this with?

Here's more info on setting the environment variable: https://www.terraform.io/docs/commands/environment-variables.html#tf_cli_args-and-tf_cli_args_name, you would want TF_CLI_ARGS="-no-color"

[MagnusBrzenk]

You might consider making -no-color the default, with -color being the optional flag. The escape characters don't even do anything in my use case except disrupt attempts to pipe the output. (I just lost a lot of time trying to figure out why I couldn't pipe the terraform show output to a bash variable; see here.)

[guildencrantz]

A growing number of applications support the NO_COLOR environment variable (if present, regardless of value, color output should be disabled) and it'd be nice to add terraform to that list.

[apparentlymart]

Is the intent of the NO_COLOR convention to disable formatting sequences entirely, or only to disable the color sequences in particular? Terraform uses both the color codes and bold/underline codes, and it isn't clear to me from the description on the website whether the bold/underline codes should still be emitted.

It seems like there are two use cases here which overlap but are not the same:

• Using Terraform in a terminal which doesn't present color in a way that is legible to its user.
• Using Terraform in a context that isn't a terminal at all, such as redirecting its output to a file or piping into other software.

I could imagine that in the first category the use of bold and underline to create additional visual hierarchy could still be useful to a sighted user, even if the color rendering is disabled for legibility. But I'm not sure if that true, and even if so I'm not sure if NO_COLOR is intended to meet the first need or the second need.

[crw]

I would scope this to the visual accessibility issue as originally reported. If NO_COLOR is to be accepted as the requirements (which seems reasonable), it is scoped to ANSI color output.

[kflathers-chwy]

Is there any update on this? NO_COLOR is definitely a rising standard, and would make shutting off colors much easier. Currently, it is incredibly hard to read the Terraform outputs in a terminal that does not support ANSI colors.

[crw]

@kflathers-chwy nothing to report, sorry!

[apparentlymart]

I think there's still some ambiguity here about what's best to do.

A relatively easy thing to implement would be for us to treat NO_COLOR as synonymous with the existing -no-color command line option, which (despite the name) actually means to disable all terminal escape sequences, including the ones that activate bold and underline. That would make it serve as a way to specify "I'm not running in a terminal at all!" and therefore make the output be plain text, suitable for display in systems that don't know how to interpret escape sequences.

However, discussion above, and the discussion I see online about the NO_COLOR environment variable, seems focused on the problem of folks either finding colors in particular distracting or having their terminal themes configured in a way that make certain colors illegible. There's some implication (but it's not explicit) that those folks would prefer to still retain bold and underline as a way to retain some amount of visual hierarchy. This interpretation is harder for us to implement because we currently only have two modes: escape codes or no escape codes.

---

My instinct is to solve the non-terminal-output problem by making Terraform check whether it's writing to a terminal or not using isatty (or the equivalent on other platforms). We historically could not rely on this for Windows reasons but I believe we do now have a reliable-enough signal about whether stdout and stderr are connected to a terminal that we could safely use that as a heuristic for automatically stripping all escape codes.

It would then be unnecessary to use either -no-color or NO_COLOR when Terraform is writing output to a file or a pipe; it would just "do the right thing" by default. The only snag here is that we currently only know how to either globally disable or globally enable escaping, so in the edge case where stderr is connected to a terminal but stdout isn't I expect we'd need to err on the side of disabling colors even for stdout.

One potential gotcha here is situations where an application is capturing Terraform's output via a pipe but still doing basic interpretation of color codes. I think some web-based automation/CI tools do this, for example: they don't go so far as full terminal emulation and so they don't run programs in a pty, but they do still recognize the basic formatting escape sequences and interpret them. If we did what I described above then Terraform would no longer output colors to such software. Some quick (non-thorough) research gives me the sense that GitHub Actions stdout/stderr is not a tty, in which case this would disable color when running in GitHub Actions, but I've not yet directly tested that.

I wonder what other software that tends to run in web-based automation wrappers does to deal with situations like this. Seems worth some further research. 🤔

---

I also feel tempted to just take the easy way out and make NO_COLOR be synonymous with -no-color too, but if we do that then we probably won't be able to weaken it later to only exclude the color codes in particular, because presumably folks will start using it instead of -no-color in situations where that option would previously have been appropriate, particularly due to the coincidental similarity of Terraform's option and the chosen environment variable name. So this is a one-way door that we need to be relatively sure about before we walk through it.

I tried to look for examples of how this decision was made in other software already supporting NO_COLOR but I wasn't able to get a good signal. It seems like a lot of software only uses colors and doesn't use bold/underline and so this question hasn't really come up very much.

Terraform uses bold and underline as follows:

• Bold for "heading-like" text, such as the first line of a diagnostic message and the beginnings of sections in the output of terraform plan.
• Underline specifically for annotating the relevant characters from source code snippets in diagnostic messages, to give a more precise indication of the problem location than we can achieve just by showing whole lines of source code.

That second one in particular is often particularly helpful for understanding an error message and so I'm loathe to just discard it completely, but would be willing to do so if that's what the NO_COLOR environment variable is intended to mean, because I think in situations like this it's more important to follow the convention so that folks who use it will get the effects they expect across many different pieces of software.

If anyone following this discussion has direct experience with using the NO_COLOR environment variable with software that normally outputs bold and underline control codes, I'd be curious to hear if there's a typical convention for whether NO_COLOR is focused exclusively on colors or if the typical expectation is for it to filter out all formatting, even if not color-related.

Thanks!

[apparentlymart]

Confirmed that GitHub Actions do not run in a tty: actions/runner#241

After some further research I've learned about a separate convention of using FORCE_COLOR to produce color codes even when the output stream isn't a tty, which is apparently how some applications are working around GitHub Actions supporting formatting sequences but not actually running programs in a terminal. Some discussion on that here: chalk/supports-color#106.

There's some research here about treatment of NO_COLOR and FORCE_COLOR across the Python ecosystem: pypa/pip#10909 (comment). Of course Terraform isn't written in Python but I'm just trying to scrounge together whatever data I can find at this point, since it seems like this is an area where there's insufficient discussion of the finer details and edge cases.

I think FORCE_COLOR may have started as an npm-specific environment variable and then become a de-facto convention elsewhere, but this specific 1, 2, 3 convention doesn't seem to be followed anywhere else I can find. Seems like the most common convention is for the mere presence of the environment variable to turn on all colors, regardless of the variable's value. I assume/hope that software that's using more advanced features like true-color codes is using termcap or similar to detect that; thankfully Terraform only uses the original 1-bit-per-channel color codes and so we don't need to worry too much about that.

I was unable to get a good signal on whether folks expect NO_COLOR to supersede FORCE_COLOR or vice-versa. Seems like different software has made different decisions on that, and in all cases I could find it seemed like an arbitrary decision so no rationale to use to tie-break.

Seems like we need to do some more research here, but I've run out of day for today so unfortunately I have to leave this inconclusive. I'd appreciate any information anyone has about how these various concerns are being treated by comparable software. Note that I'm hoping to achieve consistency with other tools in the space, and not to just choose some particular individual's preference and run with it; I specifically want to avoid implementing something that isn't quite right and then being stuck with never-ending "bug reports" about differences from other software that we can't address without breaking the compatibility promises. 😖