Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken colorization with ls and locale that differs from US #213

Open
gerritzen opened this issue Mar 24, 2022 · 0 comments
Open

Broken colorization with ls and locale that differs from US #213

gerritzen opened this issue Mar 24, 2022 · 0 comments

Comments

@gerritzen
Copy link

Colorization relies on the en_US (or similar) locale. Neither date, nor file size are colorized e.g. with LC_TIME=de_CH.UTF-8.

System: Fedora 35, grc 1.13 and zsh 5.8.1 from the official repo.

Steps to reproduce

$ LC_TIME=de_CH.UTF-8
$ ls -l

Expected result
Colorized permissions, root, file size and date

Actual result
Only permissions are colorized

Problem analysis
The regular expression \s+(\d{7}|\d(?:[,.]?\d+)?[KM])(?=\s[A-Z][a-z]{2}\s) requires a three-letter string with a trailing whitespace. This breaks on so many levels: Most languages use letters outside of A through Z, including in these abbreviations (German "Mär", Russian мар, Greek Μαρ), some locales have longer short months (févr. in French, including the dot, which is another problem). When fixing this, one should also consider that a lot of locales use dots or other symbols after the day. Compare en_US Dec 29 2017 with de_CH 29. Dez 2017 and zh_CN 12月 29 2017. A solution should at least consider these cases, potentially more.

Radical solution
Fundamentally, what grc can offer over ls --color=tty is inferior, since grc cannot offer to distinguish directories from files. It adds very little and a good part of this is broken in most of the world. Additionally it breaks colorization and formatting in zsh (see #36 which has been open for almost 6 years). Therefore, I would opt to drop support for ls completely. Not because it is hard to fix all the bugs, but because I see almost no value in it even with all the bugs fixed.

Last nitpick
In human-readable mode, files with 1K <= size < 1M are green, without it, they are unchanged. No idea, what was intended, but one should either remove the K in the regular expression mentioned above, or match 4 to 7 digits to include smaller files without human-readable sizes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant