[68] op run: no color output

I guess that op run gets the stdout&stderr by default for masking the secrets from the output. And the commands normally check that the stdout is a TTY if printing ANSI colour codes. But many commands also support --colour or other option for enforcing the colour output.

Or you could try with op run --no-masking, if you are fine to drop the masking feature.

Hey @rknshia and @r00t,

Indeed, the lack of color is caused by the fact that the stdout and stderr are no longer TTY-output streams when masking is enabled.
It is an interesting idea to persist the colors for the output when masking is enabled. I will bring this up with my team and discuss it further.

Thank you for the feedback!

It is an interesting idea to persist the colors for the output when masking is enabled. I will bring this up with my team and discuss it further.

But that logic is in most cases in the program that op run executes, so I don't think there's much that op can do. You can't just blindly add CLI options to the command. :smile:

With my simple test it seemed that op run doesn't filter any ANSI colour codes.

Thank you @r00t. It's exactly like you said.

For the masking feature, the CLI sits in-between stdout and stderr of the sub-process and the stdout and stderr of the op run command to detect any secrets printed and conceal them. Because we pass the streams that we read from rather than the TTY directly, the auto-detection used in many CLIs for using color does not detect that you're in an interactive scenario (TTY) where color should be used.

I'm afraid there's not much we can do here for the op run command to have both masking and auto-detection of colors by your sub-process.

I see two options you have:
1. Explicitly let the sub-process know you'd like to see colors. e.g. for chalk, you could use --color or $FORCE_COLOR as documented here: https://github.com/chalk/chalk#supportscolor
2. Disable masking for op run using --no-masking. In this case op run doesn't sit between the sub-processes output and the TTY and the command running in the sub-process (chalk in your case) will be able to auto-detect the output is a TTY and use colors. With this option secrets printed to stdout and stderr will not be concealed by 1Password CLI.

Although a little unsatisfying that we cannot have the best of both worlds of auto-detection and masking, I hope this explanation will help you evaluate which of the two approaches to use.

How do you feel about the 1Password CLI defaulting to the masking in this trade-off?

1P_Simon

How do you feel about the 1Password CLI defaulting to the masking in this trade-off?

I personaly think defaulting to masking is the better way, and mentioning workarounds / troubleshooting for this in a documentation/help section should be fine :)