Fd: Colourful output on Windows (in Git Bash)

[whisperity]

I've seen the talks leading up to colour output support, namely #129 #137

However, bat works and emits a colourful output, by default. Below is bat ~/Desktop/desktop.ini:

It seems colourful output can be supported.

I'm using Git Bash 2.20-something. Git Bash can be set up to run with MinTTY, which gets you a nice terminal emulator, unlike that of the default cmd. Git Bash is the nicest and best way to get Bash shell environment running for Windows, and this is like the only Shell I use on Windows, so it's surprising that if bat colours work, fd does not.

[sharkdp]

Thank you for the feedback.

How do you run fd? What does the output look like? On Windows, the LS_COLORS environment variable is typically not set, so we would only expect to get (default) colors for directories (and symlinks).

Could you try to run fd --color=always … and pipe the output to a file? This way, we could see if any ANSI escape codes are generated.

[whisperity]

Meanwhile, I checked, and the output of bat in a standard cmd.exe looks ugly. So this request could be specific to Git Bash.

I have LS_COLORS, because this is a Bash shell running inside a Windows process.

Both fd and fd --color=always produces the same output:

[sharkdp]

Could you please run

fd --color=always > output.txt

and check if the output.txt file includes ANSI escape sequences?

If not, could you please show the content of LS_COLORS?

[whisperity]

No escape sequences, only normal characters.

17:59 ~ $ echo $LS_COLORS
rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01: or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32 :*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=0 1;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*. zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.x z=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31 :*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01 ;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz =01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:* .jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm =01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35: *.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=0 1;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:* .m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01; 35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl= 01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.o gv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36 :*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=0 0;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:

[sharkdp]

(I guess this is just a copy-and-paste error, but there shouldn't be any spaces in $LS_COLORS)

Could you please run fd in a folder where you would definitely expect some entries to be colorized (e.g. with subdirectories)? In your screenshot above, I wouldn't expect anything to be colorized.

[mookid]

Note that the comment on #129 about termcolor does not apply any more: termcolor supports truecolors and ansi256 colors.

[whisperity]

@sharkdp I had no better idea to put it up on GitHub because the output is a single line, which would look idiotic with a horizontal scrollbar.
This is the default LS_COLOURS you get on a Debian(?)-based machine? I use no customisations to it, none of my (userspace) .bash or .profile files contain any changes from that.

Ran it with subdirectories. No escape sequences or anything is printed. Ran it with hidden directories, something with README.md, it's all the same.

Feels like the binary doesn't want to output colours at all.

bat's output is full of escape sequences, to the point that the bat binary works with this MinTTY shell, but doesn't work at all with the traditional cmd.exe, the escape sequences garble the output up.

[sharkdp]

Which Windows version are you on?

Could you please show the output of (run this in a new, temporary directory):

mkdir test_directory
touch test.md test.txt

fd --color=always | cat -A
echo
export LS_COLORS="di=01;34:*.md=01;31"
fd --color=always | cat -A

[whisperity]

Win7 x64 SP1 updated a few months ago.

The terminal emulator is not the standard cmd.exe it's coming from MinTTY via Git Bash git version 2.20.1.windows.1.

[sharkdp]

Ok, thank you.

The reason that this happens is the following:
https://github.com/sharkdp/fd/blob/b027b2c32285253b5866f934acc66fcd695ea649/src/main.rs#L125-L129

https://github.com/sharkdp/fd/blob/b027b2c32285253b5866f934acc66fcd695ea649/src/main.rs#L133-L134

If you have --color=always, colored_output should be true first. But then, in the second part which is only enabled on Windows, we call ansi_term::enable_ansi_support() which enables ANSI escape sequences in PowerShell/cmd.exe on Windows 10(!). If this function fails (presumably on Windows 7), the .is_ok() call returns false, and colored_output is set to false for the remainder of the fd run.

So even though your terminal emulator would actually already support ANSI escape sequences, fd switches off color support because "enabling ANSI escape sequences" failed.

I think there are a few ways forward:

• Ignore the result of ansi_term::enable_ansi_support().is_ok() if --color=always is enabled. However, this would force users MinTTY users to use --color=always all the time, which is not a good idea (when you want to pipe the fd output to another program).
• Use an (existing?) environment variable to toggle between using enable_ansi_support() or not. That would certainly work, but would add additional documentation overhead and would not work out of the box.
• Add special handling for Windows terminal emulators like MinTTY which would basically skip the whole enable_ansi_support() part. If there is an easy way to detect such terminals (without adding specific detection logic for each and every terminal emulator), that would be a good solution.
• Try to move this kind of logic into ansi_term...?
• ....

[whisperity]

You have managed to turn off escape sequences in bat when its output is going away on a pipe. Same logic could work here, and thus you don't need to specify always and use it as a default unless a pipe happens?

[sharkdp]

Yes, of course. We already do this. That's the _ => atty::is(Stream::Stdout) part which triggers in the "auto" case and checks whether Stdout is connected to a TTY (interactive terminal).

The problem is the second part. So far, we wanted to disable color support on Windows if ansi_term::enable_ansi_support() failed. This is useful for old Windows versions with cmd.exe, for example.

[sharkdp]

The way that bat "solves" this is another possibility:

• Simply ignore the result of ansi_term::enable_ansi_support().is_ok() in all cases. This would mean that colors would show up on MinTTY. However, it would also mean that ANSI escape sequences show up in cmd.exe (and PowerShell?) on older Windows versions.

[ghost]

Just ran into this.

I think fd is trying to be too smart here.

fd needs to account for situations where users operating doesnt support
ANSI (Windows 7, 8), but their terminal does (Mintty).

Currently that case is not handled. fd assumes that if users OS doesnt have
built in support, then they have no way to see color, regardless of what 3rd
party solutions might exist.

Im not sure how to fix it, but fd should be accounting for a users terminal
capabilities rather than OS capabilities.

[sharkdp]

I would be okay with the bat solution. This would be a regression for users with old Windows versions, but I guess if we have to choose, we rather provide a good default behavior for users with a recent version of Windows.

[sharkdp]

fixed via #570

[sharkdp]

This has now been released in fd v8.0.

[sharkdp]

Unfortunately, I'm going to re-open this, as I had to revert the original change in #597 due to multiple bug reports from users of older Windows versions.

As of fd 8.1.0, this will be relevant again.

[ImportTaste]

Windows 10 supports terminal colors starting with builds >= 16257

This should be able to retrieve the build number but I'm not sure what the exact output looks like: https://docs.rs/sys-info/0.6.1/sys_info/fn.os_release.html

[lzybkr]

I think ansi_term:enable_ansi_support does the right thing on older Windows versions that don't support vt escape sequences, so you can probably use this code instead:

    #[cfg(windows)]
    let colored_output = ansi_term::enable_ansi_support().is_ok();

[ImportTaste]

I compiled fd with @lzybkr's suggestion and it works on my up-to-date Windows 10 machine. It just needs to be tested on an older distribution of Windows I assume.

[sharkdp]

@lzybkr @ImportTaste Thank you for your feedback. I'm not sure I can follow.

We already use this code in the current version of fd:
https://github.com/sharkdp/fd/blob/78cde856b1064ea458f6ec7dda8c66f560aac94c/src/main.rs#L160-L161

This means that we will disable color support if enable_ansi_support() returns an error (which it does, on older Windows versions).

What I thought this issue is really about: there are some terminals that DO support ANSI escape sequences, even on older Windows versions (I have explained this here: https://github.com/sharkdp/fd/issues/469#issuecomment-532314748). At the moment, users will not see colored output on these terminals, due to enable_ansi_support() returning an error.

[sharkdp]

I am proposing the following fix: #601.

It changes two things:

• --color=always will always enable colors, even if enable_ansi_support() returns an error
• We assume that ANSI colors are supported if the TERM environment variable is set. This way, I hope to support Git Bash, MinTTY, etc. on older Windows versions.

It would be great if some users of older and newer Windows versions could test #601.

[sharkdp]

I have released this as v8.1.1: https://github.com/sharkdp/fd/releases/tag/v8.1.1

It would be great if someone could test this and report back.

[ImportTaste]

I'm on Windows 10 19041 and I'm not getting any color from the command prompt with --color=always or with TERM set.

[sharkdp]

And fd --version shows fd 8.1.1?

[ImportTaste]

Correct.

[lzybkr]

I'm getting colors w/o TERM set on 19041:

(oops, TERM showing as empty cut off, but it's not set).

[ImportTaste]

@lzybkr Ah, I see. I'm getting colors in powershell, but not cmd. Try doing it in cmd.

[lzybkr]

Colors in cmd as well - using Windows Terminal.

[lzybkr]

And colors in cmd not using Windows Terminal - regular conhost.

[ImportTaste]

Okay, my apologies, I was expecting the color on the search command I tried to spit out yellow names like it shows in the Demo (fd -e md), but they're not colored on Windows for whatever reason.

So, I guess color is working, because it colors paths blue.

[sharkdp]

Thank you both!

There are a few other (obvious?) requirements that colors work:

• The NO_COLOR environment variable must not be set
• The LS_COLORS environment variable must either be empty or set to an appropriate value. See https://github.com/sharkdp/fd#colorized-output for more information
• The file system entries that are found by fd must have an associated color within LS_COLORS

[sharkdp]

Okay, my apologies, I was expecting the color on the search command I tried to spit out yellow names like it shows in the Demo (fd -e md), but they're not colored yellow on Windows for whatever reason.

So, I guess color is working, because it colors paths blue.

Ah, I see. If you want to have similar settings as in the demo, try setting the LS_COLORS environment variable to this value:

ex=1;38;2;249;38;114:ln=0;38;2;249;38;114:or=0;38;2;0;0;0;48;2;255;74;68:bd=0;38;2;102;217;239;48;2;51;51;51:mi=0;38;2;0;0;0;48;2;255;74;68:cd=0;38;2;249;38;114;48;2;51;51;51:so=0;38;2;0;0;0;48;2;249;38;114:ow=0:di=0;38;2;102;217;239:pi=0;38;2;0;0;0;48;2;102;217;239:tw=0:st=0:no=0:*~=0;38;2;122;112;112:fi=0:*.c=0;38;2;0;255;135:*.h=0;38;2;0;255;135:*.o=0;38;2;122;112;112:*.a=1;38;2;249;38;114:*.r=0;38;2;0;255;135:*.z=4;38;2;249;38;114:*.m=0;38;2;0;255;135:*.d=0;38;2;0;255;135:*.p=0;38;2;0;255;135:*.t=0;38;2;0;255;135:*.xz=4;38;2;249;38;114:*.gv=0;38;2;0;255;135:*.rm=0;38;2;253;151;31:*.cp=0;38;2;0;255;135:*.jl=0;38;2;0;255;135:*.ll=0;38;2;0;255;135:*.kt=0;38;2;0;255;135:*.hh=0;38;2;0;255;135:*.rs=0;38;2;0;255;135:*.gz=4;38;2;249;38;114:*.cr=0;38;2;0;255;135:*.nb=0;38;2;0;255;135:*.rb=0;38;2;0;255;135:*.vb=0;38;2;0;255;135:*.ko=1;38;2;249;38;114:*.so=1;38;2;249;38;114:*.ts=0;38;2;0;255;135:*.fs=0;38;2;0;255;135:*.lo=0;38;2;122;112;112:*.ui=0;38;2;166;226;46:*css=0;38;2;0;255;135:*.el=0;38;2;0;255;135:*.ex=0;38;2;0;255;135:*.js=0;38;2;0;255;135:*.hs=0;38;2;0;255;135:*.py=0;38;2;0;255;135:*.pp=0;38;2;0;255;135:*.mn=0;38;2;0;255;135:*.la=0;38;2;122;112;112:*.md=0;38;2;226;209;57:*.td=0;38;2;0;255;135:*.sh=0;38;2;0;255;135:*.pl=0;38;2;0;255;135:*.hi=0;38;2;122;112;112:*.ml=0;38;2;0;255;135:*.ps=0;38;2;230;219;116:*.bc=0;38;2;122;112;112:*.cc=0;38;2;0;255;135:*.cs=0;38;2;0;255;135:*.pm=0;38;2;0;255;135:*.bz=4;38;2;249;38;114:*.go=0;38;2;0;255;135:*.di=0;38;2;0;255;135:*.as=0;38;2;0;255;135:*.7z=4;38;2;249;38;114:*.htm=0;38;2;226;209;57:*.tsx=0;38;2;0;255;135:*.erl=0;38;2;0;255;135:*.c++=0;38;2;0;255;135:*.pod=0;38;2;0;255;135:*.rtf=0;38;2;230;219;116:*.cfg=0;38;2;166;226;46:*.pgm=0;38;2;253;151;31:*.apk=4;38;2;249;38;114:*.bcf=0;38;2;122;112;112:*.mp3=0;38;2;253;151;31:*.fnt=0;38;2;253;151;31:*.sql=0;38;2;0;255;135:*.rpm=4;38;2;249;38;114:*.xcf=0;38;2;253;151;31:*.ilg=0;38;2;122;112;112:*.pas=0;38;2;0;255;135:*.odp=0;38;2;230;219;116:*.wmv=0;38;2;253;151;31:*.bz2=4;38;2;249;38;114:*.idx=0;38;2;122;112;112:*.aif=0;38;2;253;151;31:*.ppm=0;38;2;253;151;31:*.bsh=0;38;2;0;255;135:*.bat=1;38;2;249;38;114:*.dot=0;38;2;0;255;135:*.avi=0;38;2;253;151;31:*.dox=0;38;2;166;226;46:*.zsh=0;38;2;0;255;135:*.hpp=0;38;2;0;255;135:*.tbz=4;38;2;249;38;114:*.tmp=0;38;2;122;112;112:*.cxx=0;38;2;0;255;135:*.mli=0;38;2;0;255;135:*.bak=0;38;2;122;112;112:*.tml=0;38;2;166;226;46:*.tif=0;38;2;253;151;31:*.tar=4;38;2;249;38;114:*.svg=0;38;2;253;151;31:*.mkv=0;38;2;253;151;31:*.zip=4;38;2;249;38;114:*.bst=0;38;2;166;226;46:*.inc=0;38;2;0;255;135:*.img=4;38;2;249;38;114:*.php=0;38;2;0;255;135:*.ind=0;38;2;122;112;112:*.out=0;38;2;122;112;112:*.mpg=0;38;2;253;151;31:*.kex=0;38;2;230;219;116:*.mp4=0;38;2;253;151;31:*.wma=0;38;2;253;151;31:*.png=0;38;2;253;151;31:*.log=0;38;2;122;112;112:*.txt=0;38;2;226;209;57:*.pyc=0;38;2;122;112;112:*.pbm=0;38;2;253;151;31:*.exs=0;38;2;0;255;135:*.cgi=0;38;2;0;255;135:*.sxw=0;38;2;230;219;116:*.ps1=0;38;2;0;255;135:*.sty=0;38;2;122;112;112:*.jpg=0;38;2;253;151;31:*.jar=4;38;2;249;38;114:*.exe=1;38;2;249;38;114:*.tcl=0;38;2;0;255;135:*.swp=0;38;2;122;112;112:*.hxx=0;38;2;0;255;135:*.fon=0;38;2;253;151;31:*.lua=0;38;2;0;255;135:*.swf=0;38;2;253;151;31:*.pid=0;38;2;122;112;112:*.dpr=0;38;2;0;255;135:*.dmg=4;38;2;249;38;114:*.blg=0;38;2;122;112;112:*.m4v=0;38;2;253;151;31:*.vim=0;38;2;0;255;135:*.vob=0;38;2;253;151;31:*.odt=0;38;2;230;219;116:*.fls=0;38;2;122;112;112:*.git=0;38;2;122;112;112:*.com=1;38;2;249;38;114:*hgrc=0;38;2;166;226;46:*.mov=0;38;2;253;151;31:*.bin=4;38;2;249;38;114:*.awk=0;38;2;0;255;135:*.rst=0;38;2;226;209;57:*.fsx=0;38;2;0;255;135:*.vcd=4;38;2;249;38;114:*.pdf=0;38;2;230;219;116:*.xls=0;38;2;230;219;116:*.ico=0;38;2;253;151;31:*.flv=0;38;2;253;151;31:*TODO=1:*.ini=0;38;2;166;226;46:*.toc=0;38;2;122;112;112:*.htc=0;38;2;0;255;135:*.yml=0;38;2;166;226;46:*.pro=0;38;2;166;226;46:*.nix=0;38;2;166;226;46:*.ltx=0;38;2;0;255;135:*.fsi=0;38;2;0;255;135:*.asa=0;38;2;0;255;135:*.h++=0;38;2;0;255;135:*.pps=0;38;2;230;219;116:*.iso=4;38;2;249;38;114:*.gif=0;38;2;253;151;31:*.cpp=0;38;2;0;255;135:*.bmp=0;38;2;253;151;31:*.clj=0;38;2;0;255;135:*.arj=4;38;2;249;38;114:*.rar=4;38;2;249;38;114:*.xlr=0;38;2;230;219;116:*.aux=0;38;2;122;112;112:*.ics=0;38;2;230;219;116:*.mid=0;38;2;253;151;31:*.csv=0;38;2;226;209;57:*.ttf=0;38;2;253;151;31:*.mir=0;38;2;0;255;135:*.doc=0;38;2;230;219;116:*.sbt=0;38;2;0;255;135:*.kts=0;38;2;0;255;135:*.deb=4;38;2;249;38;114:*.pkg=4;38;2;249;38;114:*.bib=0;38;2;166;226;46:*.bbl=0;38;2;122;112;112:*.elm=0;38;2;0;255;135:*.ogg=0;38;2;253;151;31:*.xml=0;38;2;226;209;57:*.ods=0;38;2;230;219;116:*.bag=4;38;2;249;38;114:*.tgz=4;38;2;249;38;114:*.wav=0;38;2;253;151;31:*.csx=0;38;2;0;255;135:*.tex=0;38;2;0;255;135:*.gvy=0;38;2;0;255;135:*.inl=0;38;2;0;255;135:*.epp=0;38;2;0;255;135:*.ipp=0;38;2;0;255;135:*.xmp=0;38;2;166;226;46:*.def=0;38;2;0;255;135:*.ppt=0;38;2;230;219;116:*.dll=1;38;2;249;38;114:*.sxi=0;38;2;230;219;116:*.otf=0;38;2;253;151;31:*.yaml=0;38;2;166;226;46:*.make=0;38;2;166;226;46:*.bash=0;38;2;0;255;135:*.toml=0;38;2;166;226;46:*.epub=0;38;2;230;219;116:*.h264=0;38;2;253;151;31:*.html=0;38;2;226;209;57:*.less=0;38;2;0;255;135:*.mpeg=0;38;2;253;151;31:*.json=0;38;2;166;226;46:*.psm1=0;38;2;0;255;135:*.fish=0;38;2;0;255;135:*.hgrc=0;38;2;166;226;46:*.psd1=0;38;2;0;255;135:*.flac=0;38;2;253;151;31:*.purs=0;38;2;0;255;135:*.lisp=0;38;2;0;255;135:*.lock=0;38;2;122;112;112:*.jpeg=0;38;2;253;151;31:*.rlib=0;38;2;122;112;112:*.dart=0;38;2;0;255;135:*.orig=0;38;2;122;112;112:*.java=0;38;2;0;255;135:*.pptx=0;38;2;230;219;116:*.xlsx=0;38;2;230;219;116:*.conf=0;38;2;166;226;46:*.diff=0;38;2;0;255;135:*.docx=0;38;2;230;219;116:*.tbz2=4;38;2;249;38;114:*shadow=0;38;2;166;226;46:*.toast=4;38;2;249;38;114:*.ipynb=0;38;2;0;255;135:*passwd=0;38;2;166;226;46:*.mdown=0;38;2;226;209;57:*.xhtml=0;38;2;226;209;57:*.scala=0;38;2;0;255;135:*.class=0;38;2;122;112;112:*.dyn_o=0;38;2;122;112;112:*.cache=0;38;2;122;112;112:*.shtml=0;38;2;226;209;57:*.cmake=0;38;2;166;226;46:*.swift=0;38;2;0;255;135:*.cabal=0;38;2;0;255;135:*.patch=0;38;2;0;255;135:*README=0;38;2;0;0;0;48;2;230;219;116:*INSTALL=0;38;2;0;0;0;48;2;230;219;116:*TODO.md=1:*.gradle=0;38;2;0;255;135:*.flake8=0;38;2;166;226;46:*COPYING=0;38;2;182;182;182:*.dyn_hi=0;38;2;122;112;112:*.config=0;38;2;166;226;46:*.groovy=0;38;2;0;255;135:*.ignore=0;38;2;166;226;46:*LICENSE=0;38;2;182;182;182:*.matlab=0;38;2;0;255;135:*.desktop=0;38;2;166;226;46:*Makefile=0;38;2;166;226;46:*Doxyfile=0;38;2;166;226;46:*.gemspec=0;38;2;166;226;46:*TODO.txt=1:*setup.py=0;38;2;166;226;46:*README.md=0;38;2;0;0;0;48;2;230;219;116:*.rgignore=0;38;2;166;226;46:*configure=0;38;2;166;226;46:*.DS_Store=0;38;2;122;112;112:*.fdignore=0;38;2;166;226;46:*.kdevelop=0;38;2;166;226;46:*.markdown=0;38;2;226;209;57:*COPYRIGHT=0;38;2;182;182;182:*.cmake.in=0;38;2;166;226;46:*INSTALL.md=0;38;2;0;0;0;48;2;230;219;116:*.gitignore=0;38;2;166;226;46:*.gitconfig=0;38;2;166;226;46:*SConscript=0;38;2;166;226;46:*CODEOWNERS=0;38;2;166;226;46:*SConstruct=0;38;2;166;226;46:*README.txt=0;38;2;0;0;0;48;2;230;219;116:*Dockerfile=0;38;2;166;226;46:*.scons_opt=0;38;2;122;112;112:*.localized=0;38;2;122;112;112:*Makefile.am=0;38;2;166;226;46:*Makefile.in=0;38;2;122;112;112:*.gitmodules=0;38;2;166;226;46:*.synctex.gz=0;38;2;122;112;112:*MANIFEST.in=0;38;2;166;226;46:*LICENSE-MIT=0;38;2;182;182;182:*.travis.yml=0;38;2;230;219;116:*configure.ac=0;38;2;166;226;46:*.applescript=0;38;2;0;255;135:*appveyor.yml=0;38;2;230;219;116:*.fdb_latexmk=0;38;2;122;112;112:*CONTRIBUTORS=0;38;2;0;0;0;48;2;230;219;116:*.clang-format=0;38;2;166;226;46:*LICENSE-APACHE=0;38;2;182;182;182:*CMakeCache.txt=0;38;2;122;112;112:*INSTALL.md.txt=0;38;2;0;0;0;48;2;230;219;116:*.gitattributes=0;38;2;166;226;46:*CMakeLists.txt=0;38;2;166;226;46:*CONTRIBUTORS.md=0;38;2;0;0;0;48;2;230;219;116:*CONTRIBUTORS.txt=0;38;2;0;0;0;48;2;230;219;116:*.sconsign.dblite=0;38;2;122;112;112:*requirements.txt=0;38;2;166;226;46:*package-lock.json=0;38;2;122;112;112:*.CFUserTextEncoding=0;38;2;122;112;112

[ImportTaste]

Doesn't seem to be working. I did fd --color=always -e md and then an echo %ex% to show that I applied the variable. It's cut off in the screenshot due to length, but it's all there.

[sharkdp]

The name of the variable is LS_COLORS. The value begins with ex=1;…

[ImportTaste]

Oh, I seem to be an idiot.

Ok, it works, sorry about that.

[sharkdp]

No worries. I think we should update the Installation/Windows section in the README to inform Windows users about the LS_COLORS environment variable. What do you think?

How are environment variables permanently set in PowerShell/cmd.exe?

[ImportTaste]

cmd uses setx (defaults to current user, to set it on local machine you use the /m switch)

For PowerShell:

[Environment]::SetEnvironmentVariable("LS_COLORS", "VALUE", 'User')
[Environment]::SetEnvironmentVariable("LS_COLORS", "VALUE", 'Machine')

Though PowerShell can use setx as well. There is a way to do this through native cmdlets and not the .NET method, but it's needlessly complicated.

[sharkdp]

Another option would be to ship fd with a more "complete"/colorful version of LS_COLORS for cases when it has not been set by the user. But that should be discussed in a separate ticket.

Concerning this ticket: We now know that colors work on Windows 10 with cmd and PowerShell. However, the ticket was originally opened by someone running "Win7 x64 SP1" and using Git Bash. Can someone please report back if colors work in this setting?

[claudetete]

Concerning this ticket: We now know that colors work on Windows 10 with cmd and PowerShell. However, the ticket was originally opened by someone running "Win7 x64 SP1" and using Git Bash. Can someone please report back if colors work in this setting?

Colors works running Windows Server 2008 and using Git Bash (git 2.26.0, nor LS_COLORS nor NO_COLORS are set) but it is much slower than with --color=never around 5 times slower (testing with large output)

[sharkdp]

Colors works running Windows Server 2008 and using Git Bash (git 2.26.0, nor LS_COLORS nor NO_COLORS are set) but it is much slower than with --color=never around 5 times slower (testing with large output)

That is somewhat expected. Without colors, we don't have to print any ANSI escape codes. Terminal rendering will also be faster.

[whisperity]

@sharkdp Ever since I moved my personal computer to Win 10, but still using Git Bash, I can check for you once I'm out of work.

[claudetete]

Concerning this ticket: We now know that colors work on Windows 10 with cmd and PowerShell. However, the ticket was originally opened by someone running "Win7 x64 SP1" and using Git Bash. Can someone please report back if colors work in this setting?

Colors works running Windows Server 2008 and using Git Bash (git 2.26.0, nor LS_COLORS nor NO_COLORS are set)

Windows Server 2008 R2 is a server variant of Windows 7 and have both SP1.

[whisperity]

Alright, just remembered this issue, here are the results:

cmd: fd or even fd --color=always doesn't work.

Git Bash:

bat works in both places:

Anyways, it seems the "Git Bash" part of the issue is indeed fixed.

[sharkdp]

cmd: fd or even fd --color=always doesn't work.

• which Windows version are you on?
• Could you please run the fd command in the same folder as under Git Bash? You need some file system entries that are actually colorized (like directories). Or you need to set LS_COLORS (see above: https://github.com/sharkdp/fd/issues/469#issuecomment-633605700).

[whisperity]

* Could you please run the `fd` command in the same folder as under Git Bash?

Huh! It wasn't making executable colourful by default! Doing it somewhere where I have .jpg files, directories, etc, I'm getting the colours! 🏆