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

[Un1q32]

• 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

[zwpaper]

we change the color lib to a new one for the theme feature, maybe there is some color difference between the 2 libs.

please unset the LS_COLORS and let's make sure it is not working or there is a color difference.

[Un1q32]

The issue is still present when I unset LS_COLORS

[zwpaper]

nothing changed for both 0.20.1 and 0.21.0?

it seems like the difference between the 2 default colors.

how are the colors present if the LS_COLOR you mentioned is set?

[Un1q32]

what I originally thought was the issue (the new version didnt obey my terminal color scheme) was incorrect, what seems to be happening is that 0.21.0 is using the darker versions of the terminal colors rather than the lighter ones that the old version uses

[zwpaper]

my point is that even you unset the LS_COLORS, the old version still shows the color you expected, so maybe this is not related to LS_COLORS, it is caused by the color lib changes.

some minor differences happened when we are changing the lib, maybe this is some cases like that.

maybe we need to figure out why the LS_COLORS not working, but it seems really complicated...

[meain]

@zwpaper One possibility that I can think of is https://github.com/Peltoche/lsd/blob/1a63ccced0203f2131ad26682da849b16aa66a5d/src/color.rs#L246. But from what I understand this is correct as per https://github.com/crossterm-rs/crossterm/blob/db956267f80744b1d8ab08dcd7d92ee21b7a60f2/src/style/types/color.rs#L126 .

I am NOT able to reproduce the difference between 19 and 21 though.

[zwpaper]

yes, this also recalls me of this red difference when implementing the theme feature.

I was also confused about this issue as the LS_COLORS env seems not working, I tried the env but nothing changed in my terminal, but I am not good at LS_COLORS

[meain]

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

[Un1q32]

classic ls has the colors that 0.20.1 uses

[meain]

I have a feeling that this may be linked to https://github.com/Peltoche/lsd/issues/248

[meain]

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]

Sorry for the delay, but I did some more digging on this. The 34 comes from ansi-term using just 8 colors and it is equivalent to 4 in crossterm which expects 256 color support.

ref: https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797

---

With that said, I have a feeling the the latest lsd is already doing the right thing. @OldWorldOrdr What does gnu ls give you for color with export LS_COLORS="di01;34" set. \ls --color=always?

---

EDIT: I missed you comment that classic ls used the old colors. Now this is starting to get confusing.

[meain]

@zwpaper Could you set export LS_COLORS="di=01;31" and see if /tmp/one/lsd-0.20.1-x86_64-unknown-linux-gnu/lsd && \ls --color=always && lsd gives you the same colors. It won't be the same shade of red as me, but at least they should be same between them.

What I don't get is how the old one has different colors in the issue screenshot

[meain]

@OldWorldOrdr Could you try building lsd after applying this patch and see if it uses the old colors.

diff --git a/src/color.rs b/src/color.rs
index b5636bf..fedad32 100644
--- a/src/color.rs
+++ b/src/color.rs
@@ -243,12 +243,12 @@ fn to_content_style(ls: &lscolors::Style) -> ContentStyle {
         },
         lscolors::style::Color::Fixed(n) => Color::AnsiValue(*n),
         lscolors::style::Color::Black => Color::Black,
-        lscolors::style::Color::Red => Color::DarkRed,
-        lscolors::style::Color::Green => Color::DarkGreen,
-        lscolors::style::Color::Yellow => Color::DarkYellow,
-        lscolors::style::Color::Blue => Color::DarkBlue,
-        lscolors::style::Color::Magenta => Color::DarkMagenta,
-        lscolors::style::Color::Cyan => Color::DarkCyan,
+        lscolors::style::Color::Red => Color::Red,
+        lscolors::style::Color::Green => Color::Green,
+        lscolors::style::Color::Yellow => Color::Yellow,
+        lscolors::style::Color::Blue => Color::Blue,
+        lscolors::style::Color::Magenta => Color::Magenta,
+        lscolors::style::Color::Cyan => Color::Cyan,
         lscolors::style::Color::White => Color::White,
     };
     let mut style = ContentStyle {

If you are not scared of running a random binary that a stranger on the internet gave you, here (md5: 0b1e358c79fc4b159bf3161de985b784) is a built version.

[Un1q32]

@OldWorldOrdr Could you try building lsd after applying this patch and see if it uses the old colors.

diff --git a/src/color.rs b/src/color.rs
index b5636bf..fedad32 100644
--- a/src/color.rs
+++ b/src/color.rs
@@ -243,12 +243,12 @@ fn to_content_style(ls: &lscolors::Style) -> ContentStyle {
         },
         lscolors::style::Color::Fixed(n) => Color::AnsiValue(*n),
         lscolors::style::Color::Black => Color::Black,
-        lscolors::style::Color::Red => Color::DarkRed,
-        lscolors::style::Color::Green => Color::DarkGreen,
-        lscolors::style::Color::Yellow => Color::DarkYellow,
-        lscolors::style::Color::Blue => Color::DarkBlue,
-        lscolors::style::Color::Magenta => Color::DarkMagenta,
-        lscolors::style::Color::Cyan => Color::DarkCyan,
+        lscolors::style::Color::Red => Color::Red,
+        lscolors::style::Color::Green => Color::Green,
+        lscolors::style::Color::Yellow => Color::Yellow,
+        lscolors::style::Color::Blue => Color::Blue,
+        lscolors::style::Color::Magenta => Color::Magenta,
+        lscolors::style::Color::Cyan => Color::Cyan,
         lscolors::style::Color::White => Color::White,
     };
     let mut style = ContentStyle {

If you are not scared of running a random binary that a stranger on the internet gave you, here (md5: 0b1e358c79fc4b159bf3161de985b784) is a built version.

this worked perfectly.

[zwpaper]

it is all the same color in my case 🤣, both dark and light

[meain]

@zwpaper Yeah, same for me. In fact, if I switch it using the diff I mentioned it gives me different colors compared to gnu ls. What I have no clue now is how the old has different colors for OP.

@OldWorldOrdr If you pipe lsd to less (or redirect output to a file) with color always, you will get the actual ansi escape sequences. Could you paste that here. lsd --color=always -d /tmp. It will look something like /tmp.

[Un1q32]

@meain

0.20.1:

file
folder
script.sh

0.21.0:

file
folder
script.sh

0.21.0 with patch:

file
folder
script.sh

[zwpaper]

hi @OldWorldOrdr, could you also paste the GNU ls piped contents with \ls --color=always

[Un1q32]

@zwpaper

file
folder
script.sh

[meain]

@OldWorldOrdr I'm not sure how you configure Window terminal, but could you paste the color configuration.

Ideally from what I understand both 1;34 and 38;5;4 1 should give you the same color. echo '\x1b[1;34m16 color blue\x1b[0m | \x1b[38;5;4m\x1b[1m256 color dark \x1b[0m | \x1b[38;5;12m\x1b[1m256 color light\x1b[0m'

.

[Un1q32]

@meain

[meain]

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.

[beedaddy]

I hope this is the right place for this comment (since it's not Windows but Arch Linux with GNOME 41.3): I, too, stumbled over the issue, that the colors for ls are different to the colors of lsd (version 0.21.0) as illustrated here: $LS_COLORS is not set. If there's anything I can do/test, please let me know.

[meain]

@beedaddy See my previous message here.

You said you are using gnome. Just from that, if you are using gnome-terminal then this checkbox at the bottom is the one that I am talking about in my previous message. See if disabling this will make both of the colors the same.

[beedaddy]

Thanks for reminding me about this option. Disabling this option results in the same (?) color: a dark blue. So the problem is that lsd irgnores the (enabled) option?

[meain]

Thanks @beedaddy for verifying the issue. The issue here is that older version of lsd relied on 8/16 colors which would change colors based on if this option is enabled or not. The newer version of lsd uses 256 color pallete which does not get affected by this setting.

IMO the "right" color is the dark variant. The ideal fix here is to not do a translation from 8/16 color to 256 automatically, but from what I understand crossterm does not currently have support for using 8/16 color pallete.

[Un1q32]

its been nearly a year and lsd still uses the wrong colors for me. Heres an up to date screenshot

[Un1q32]

is there a way to force it to use bright colors instead of dark bold colors?

[Un1q32]

refuses to make text bold

[meain]

is there a way to force it to use bright colors instead of dark bold colors?

You will have to use 256 colors LS_COLORS to get bright ones. For bright blue, it would be something like di=38;5;12. In general, you can use 38;5;<x> where x is the color. You can list of all the colors using the following script:

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

[Un1q32]

@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

[magus424]

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.