tricky grid issue with very long filenames

[PThorpe92]

Hey Terts, just leaving this here from our discussion in eza matrix.

So although this really isn't behavior I think we are worried too much about for eza, due to how long the filenames need to be to trigger this, I'm sure this might be a concern for uutils with the strict GNU compatibility.

Just to review, in a sufficiently large directory, with sufficiently long enough filenames, term_grid will attempt to fill the second column in an uneven fashion. Sometimes it will stop when it encounters a row it doesn't have space for, other times it will only continue for a few rows despite having plenty of space. I encourage you to run the script multiple times if you'd like to see some of the different cases of output.

Here is a little bash script I wrote up that should reproduce this on your branch of eza from your PR. (needs to be ran from inside eza root directory)

#!/bin/bash
mkdir testdir && cd testdir

for i in {10..45}; do
	file=$(date +%N | sha256sum | base64 | head -c $i)
	touch "$file"
done

for i in {10..45}; do
	file=$(date +%N | sha256sum | base64 | head -c $i)
	mkdir "$file"
done

really_long_filename=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 80)
touch "Xa$really_long_filename"

cd ..
cargo run -- -lAhF --icons --grid --hyperlink testdir

This was kind of tricky to make perfectly reproducible because the script relies on random output, and the behavior is different based on how far down the list of files the long file is alphabetically. But after some time playing with it, I think it works just about every time. worst case scenario, you might have to delete the testdir and try it again but it seems to work every time for me now.

Thanks for all the help and support with eza! we really appreciate it. LMK if there's anything else I can do.

[tertsdiepraam]

Thank you! This is a great report :)