lsd: Don't convert from 16 to 256 colors in `LS_COLORS`

os: Windows 10 (Arch Linux in WSL)
lsd --version: 0.21.0
echo $TERM: xterm-256color
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=01;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:.xz=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=01;35:.mpeg=01;35:.m2v=01;35:.mkv=01;35:.webm=01;35:.webp=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:.ogv=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=00;36:.oga=00;36:.opus=00;36:.spx=00;36:.xspf=00;36:

Expected behavior

If applicable, add the output of the classic ls command (\ls -la) in order to show the buggy file/directory.

lsd should respect my terminal color scheme, as it does in 0.20 and 0.19

Actual behavior

If the application panics run the command with the trace (RUST_BACKTRACE=1 lsd ...). In case of graphical errors, add a screenshot if possible.

lsd does not respect my terminal color scheme

Screenshot (9)

About this issue

Original URL
State: open
Created 2 years ago
Comments: 33 (30 by maintainers)

Most upvoted comments

I think I was able to track down what is going on.

Taking the example of di=1;34, in lscolors, 34 is mapped to lscolors::Colors::Blue (https://github.com/sharkdp/lscolors/blob/c6e191b91f637058ba932a4f7b065f2e19d8a1ba/src/style.rs#L245) which was initially a ansi_term only lib which also mapped ansi_term::Color::Blue to 34(https://github.com/ogham/rust-ansi-term/blob/ff7eba98d55ad609c7fcc8c7bb0859b37c7545cc/src/style.rs#L273).

The crossterm integration came later and for crossterm crossterm::Color::DarkBlue , which we map to(https://github.com/Peltoche/lsd/blob/1a63ccced0203f2131ad26682da849b16aa66a5d/src/color.rs#L249) is using 4(https://github.com/crossterm-rs/crossterm/blob/db956267f80744b1d8ab08dcd7d92ee21b7a60f2/src/style/types/color.rs#L130) which matches with what neofetch(https://github.com/dylanaraps/neofetch/blob/ccd5d9f52609bbdcd5d8fa78c4fdb0f12954125f/neofetch#L646) shows. Even lscolors maps to crossterm::Color::Blue (https://github.com/sharkdp/lscolors/blob/bc95124f23d2f1c14616e6a97f5ae9e6ab786697/src/style.rs#L61) which is still not 34.

Let me do some more research, but if this is the case we will have to solve this upstream in lscolors as well.

meain on Jan 23, 2022

I’ve been running into this same issue; whatever code/library/etc is mapping \e[1;34m to \e[38;5;4m\e[1m seems to be the issue; the behavior between those two sets of codes is not necessarily identical, so this conversion introduces unexpected behavior.

This is why classic ls works correctly with \e[1;34m as it isn’t trying to “upgrade” it to 256 colors where the behavior can be different.

If whatever is converting it to 256 just stopped doing that, it would probably fix everything.

magus424 on Feb 26, 2024

@meain ur code didn’t work so i fixed it for u working code:

for code in {0..255}; do
  printf "\e[38;05;${code}m$(printf %03d $code)\n"
  [ $((${code} % 16)) -eq 15 ] && echo
done

Un1q32 on Dec 2, 2022

It just hit me. A lot of terminal emulators enable “Use bright text for bold colors” option. With this enabled, if something is bold, it automatically makes it bright. This I believe does not work on 256 color pallet. So, in your case, the old version of lsd was trying to show directories in bold, but with dark colors (because of di=1;34 … 1 = bold 34 = blue), but Windows terminal automatically makes it bright and that is how to end up with the bright variants of the colors in the old version of lsd. Try disabling this option if this is available and see if the colors in both versions match.

meain on Feb 10, 2022

LS_COLORS works as expected. The reason why you did not see a change is probably because this is close to the default.

meain on Jan 19, 2022