eza icon indicating copy to clipboard operation
eza copied to clipboard

bug: with many files, the grid option doesn't work

Open kiyoon opened this issue 1 year ago • 12 comments

  • The version of eza being used (eza --version): 0.17.2
  • The command-line arguments you are using: eza, eza --icons auto etc.
  • Your operating system and hardware platform: Ubuntu 20.04

Without the -1 option it still prints every file per line. All of the file names are shown as such, with 4 character codes.

image

kiyoon avatar Jan 25 '24 04:01 kiyoon

Hey thanks for reporting the issue. A couple questions,

Could you list out the rest of the exact arguments you are using?

how many files in a directory is "many", and the same args in a smaller directory is producing different output?

All of the file names are shown as such, with 4 character codes.

Do you mean that those aren't the file names?

Trying to re-create this issue, so as much info as you can give would be helpful :+1:

PThorpe92 avatar Jan 25 '24 15:01 PThorpe92

@PThorpe92 No argument was needed to reproduce this. It works like this with whatever I use, with or without --icons for example. With exa the grid works well.

This was enough to reproduce:

for a in {0001..0401}; do touch $a; done
eza --icons auto
  • With 400 files it works as expected, but not with 401 files.
  • Without --icons I needed to create more files, like 600 to reproduce. (don't know the exact boundary)
  • I'm using Wezterm ($TERM=wezterm) and I found out that with Gnome Terminal the issue doesn't exist.
  • The size of the terminal seems to matter. The issue exists with the terminal fit to full screen but not with smaller window.

kiyoon avatar Jan 26 '24 02:01 kiyoon

Interesting how this doesn't reproduce in gnome. Thanks for the info I'll try to repro this as I use wezterm as well.

PThorpe92 avatar Jan 26 '24 04:01 PThorpe92

@PThorpe92 My theory is that there exist some edge cases where it doesn't align the grid, and maybe with gnome terminal if I had the exact same column it might happen too.

kiyoon avatar Jan 26 '24 05:01 kiyoon

Strange, I expected to be able to reproduce this, as I have seen kind of random errors in the past with grid width. but I tried on Wez, alactritty, kitty, xfce-term and xterm on eza v0.17.3 and got the proper amt of columns every time, even at different window sizes. Perhaps try upgrading to17.3 and see if that fixes it?

PThorpe92 avatar Jan 27 '24 17:01 PThorpe92

Thanks for the time to try many settings but I'm sorry you couldn't reproduce. I tried with the v0.17.3 but the issue still exists.

Additional info that may be helpful

$ tput cols
166

$ tput lines
34

It seems like the number of row doesn't matter, but the width matters. I tried with smaller font size and set the width to 166, and I can still reproduce it.

kiyoon avatar Jan 27 '24 18:01 kiyoon

OK, with Gnome Terminal it happens exactly the same as Wezterm so it wasn't the issue with the terminal. My bad.

With width=166 you should be able to reproduce it.

kiyoon avatar Jan 27 '24 18:01 kiyoon

Yeah after quite a bit of testing, I was able to reproduce it. Super strange, because the command that I use for my alias (alias ls="eza --icons --color-scale -lAh --git --git-repos --no-permissions --grid") will display properly, but eza --icons will not.

but eza --icons -lA --grid will display properly, however if you take away the -lA, --icons --grid will not...

Very strange indeed, especially because with cols at 158, and 176, it works as expected :confused:

Looking into this :+1:

PThorpe92 avatar Jan 28 '24 17:01 PThorpe92

That is really weird! But I'm glad you were able to reproduce it and I appreciate it for maintaining the awesome project :smile:

kiyoon avatar Jan 30 '24 12:01 kiyoon

I'm looking into this, it's a bug in uutils-term-grid. I've been able to reproduce it in the test suite there.

tertsdiepraam avatar Feb 17 '24 11:02 tertsdiepraam

I've fixed this in https://github.com/uutils/uutils-term-grid/pull/34, but we'll need to port eza to use the new version of uutils-term-grid to use the fix. It was a weird combination of small mistakes in the computation of some heuristics, which is why it was so sensitive to those specific values.

tertsdiepraam avatar Feb 17 '24 12:02 tertsdiepraam

Thank you so much!

kiyoon avatar Feb 18 '24 07:02 kiyoon