It appears that watch
is not interpret the implicit 'reset' color code ^[m
. It does interpret the explicit code ^[0m
.
Does anyone know how to fix this? Or does it sound like a bug and I need to contact the maintainers of watch
?
Why I'm asking:
I'm using watch
with git log
, and git log
uses implicit resets ^[m
.
Example:
$ watch -c git log --oneline --decorate --source --graph --color=always
What it should look like is:
$ git log --oneline --decorate --source --graph --color=always
Investigation
If we don't include the -c
(--color
) option on watch
, we can see that the ANSI escape codes are there:
Every 2.0s: git log --oneline --decorate --source --graph --color=always Fri Sep 28 08:17:42 2018
* ^[33m9db218b^[m HEAD^[33m (^[m^[1;36mHEAD^[m^[33m -> ^[m^[1;32mmaster^[m^[33m, ^[m^[1;33mtag: v0.8.0b5^[m^[33m, ^[m^[1;31morigin/master^[m^[33m, ^[m^[1;31morigin/HEAD^[m^[33m)^[m Doc updates for v0.8.0b5 release
* ^[33mfd342d9^[m HEAD Update changelog [ci skip]
* ^[33md1af865^[m HEAD Update changelog
* ^[33m70889fa^[m HEAD Merge branch 'testing-updates' into 'master'
There's a lot going on in the above example - let's simplify it:
Prove that we're escaping things correctly:
$ echo -e "\033[33myellow\033[mnormal"
Send it to watch
Note: the -e
arg on echo
is not parsed because we're quoting things. watch
now handles the color codes.
$ watch -c 'echo -e "\033[33myellow\033[mnormal"'
Remove the -c
flag from watch
$ watch 'echo -e "\033[33myellow\033[mnormal"'
Every 2.0s: echo -e "\033[33myellow\033[mnormal" Fri Sep 28 08:29:26 2018
-e ^[33myellow^[mnormal
This looks as expected.
Using the explicit ^[0m
reset code works
$ watch -c 'echo -e "\033[33myellow\033[0mnormal"'
Versions
Primarily tested under WSL: Window 10 Pro, v1803, build 17134.286
$ watch -v
watch from procps-ng 3.3.10
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.5 LTS
Release: 16.04
Codename: xenial
$ uname -a
Linux redacted-hostname 4.4.0-17134-Microsoft #285-Microsoft Thu Aug 30 17:31:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
$ git --version
git version 2.7.4
Also tested using PuTTY to a linux machine. Same version information as above, just not using WSL.
Looks like it was fixed in version 3.3.12 of
procps
, which containswatch
:https://gitlab.com/procps-ng/procps/issues/12
https://gitlab.com/procps-ng/procps/commit/6fcb690099bd681930946492e8a93c61e82249d8