ansi colors not displayed within linux watch command #840

Open
gberche-orange opened this Issue May 12, 2016 · 7 comments

Comments

Projects
None yet
5 participants

gberche-orange commented May 12, 2016

Starting with 6.17.1 the watch -c cf a is not displaying colors anymore. Suspecting that the colors improvements brought in 6.17.1 are misleadingly detecting the "watch-exposed terminal" as not supporting colors, and regressed. The same command is properly displaying colors in 6.17.0 version

nb: some related diagnostic in some other cf-unrelated cli commands

Command

watch -c cf a

CLI Version

Reproduces in

$ cf-6.17.1 -v
cf version 6.17.1+2ca614d-2016-05-02

$ cf -v
cf version 6.18.0+b22884b-2016-05-10

Platform Details

Ubuntu:

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=15.10
DISTRIB_CODENAME=wily
DISTRIB_DESCRIPTION="Ubuntu 15.10"

Shell

Bash

$ bash --version
GNU bash, version 4.3.42(1)-release (x86_64-pc-linux-gnu)
Collaborator

cf-gitbot commented May 12, 2016

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/119446319

The labels on this github issue will be updated when the story is started.

Member

XenoPhex commented May 12, 2016

Recently the CF CLI switched color libraries in order to support windows. This color library is significantly more robust for things like supporting the same colors, highlighting words, etc. However, it also detects whether you are in a TTY session. If you are not in a TTY session, this library will automatically not output colors. Whenever you run a CF command inside another command or pipe it through a series of commands, the command knows it's not in a TTY and will not output colors.

There is no way to cleanly force colors to be on for these situations.

@cf-gitbot cf-gitbot added unscheduled and removed scheduled labels May 12, 2016

thanks @XenoPhex for looking int this issue. Any chance to contribute to this library to add a configureable mode to bypass the tty detection and force color output ?

In terms of UX for cf cli, this could end-up in new accepted values for the CF_COLORS env var
/CC @dkoper

CF_COLOR=true|false|always                     Controls output colorization

This would be similar to common pattern used in ls command:

$ man ls
[...]
       --color[=WHEN]
              colorize the output; WHEN can be 'never', 'auto', or 'always' (the default); more info below
[...]
     Using  color  to  distinguish  file types is disabled both by default and with --color=never.  With --color=auto, ls emits color codes only when standard
       output is connected to a terminal.  The LS_COLORS environment variable can change the settings.  Use the dircolors command to set it.
Contributor

krishicks commented Jul 27, 2016

This also affects the cf-resource in Concourse, which is a big sadface.

cc @xoebus

Contributor

dkoper commented Aug 30, 2016

We'd like to address this issue in the next release.

ls and grep default to always but commonly aliased to --color=auto hence the need for --color in watch ls --color.

Rather than introducing a new environment variable, would a global --color option satisfy?
watch -c cf a --color
with --color [never|always|auto], defaulting to always if no value specified.
cf config --color would accept the same values, aliasing never to false and auto to true for compatibility, which applies when running any cf command without the --color flag.
->@gberche-orange @krishicks

@dkoper thanks for priorizing this issue.

+1 for your proposal to add a --color common flag to all commands e.g. in cf a --color always as well as a cf config --color applying when no color flag is provided in a given command.

Contributor

dkoper commented Aug 31, 2016

Sorry, I'd like to take that back, I had missed we already expose CF_COLOR!

Instead, I'd like to address this by fixing the behaviour of this environment variable as it was before: true means force colors. So e.g. watch -c CF_COLOR=true cf a should work again.

At the same time, I'd like to extend cf config --color with an auto value, which would be the default.

Would that work for you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment