bug: The 'sb' option in EZA_COLORS seems not working

[pi314]

Basic information:

• The version of eza being used (eza --version):
  v0.18.18

• The command-line arguments I was using:
  eza --long --binary --header

• My shell and terminal:
  Zsh + Mac default Terminal app

• My operating system and hardware platform:
  macOS Sonoma 14.5 on MacBook Pro 2019

---

sn=1;35:sb=0;35 doesn't separate number and units:

I tried several combinations on sn and sb, and it seems like sb is not taking effect.
ub, uk, um, ug, ut are not working, either (ug and ut were not tested.)

Thank you for maintaining this project, though.
I was sad when exa became broken on MacPorts, and sadder when brew told me exa was disabled because it's not maintained.

[bew]

Might be a duplicate of #682.
Could you try the PR #975 maybe?

[pi314]

Thanks for the quick reply!

--color-scale-mode=fixed makes eza behave exactly what I need, but it feels like a workaround.

I guess I understand why you want to submit a pull request. The default behavior, that sb is silently ignored by --color-scale-mode=gradient, is a bit confusing.

---

(The following information is off-topic, I hope it worth writing down)

If I understand correctly, the color scaling feature "scales" the color to the range of size/age?
But the "color" and "scaling" here seems not very well-defined.

With EZA_COLOR='reset', the color scale seems to be green→yellow→red and their gradients.
But in the middle I see an orange-ish color:

With EZA_COLORS='sn=35', the color scale is the gradient of magenta:

With EZA_COLORS='sn=38;5;127', which is the closest color I can find from magenta, it become grayscale.
It looks like eza could only handle gradient starting from VT-100 8 colors:

Also EZA_COLORS='sn=35' and EZA_COLORS='sn=1;35' behaved the same.

It would be great if a gradient pattern could be defined from any color, maybe like calculating a curve from color17 to color231 that passes the specified color and use it for the color scale:

If that could be achieved, eza might no longer needs to ignore EZA_COLORS in gradient mode.
From there, gradient might be applied on sn and sb, separately.

Put those ideas aside, as a random eza user, I think your patch is the best thing we can do.
It sounds reasonable to ignore scale.size and scale.age if the scale.mode is already fixed.

[pi314]

It's a duplicate of #682.

Sorry that I don't have Rust development environment so I didn't actually try #975.

The above tests were all based on eza v0.18.18.