-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
uucore: add alacritty to the list of terminals that support colors #6725
base: main
Are you sure you want to change the base?
Conversation
Any value of TERM with glob pattern `alacritty*` will be matched. Fixes uutils#6722
From the tests, it seems that a |
GNU testsuite comparison:
|
As you saw, this test probably needs to be updated:
|
sorry but why not fixing the test? |
Since it's a test based on a fixture, I fixed it by updating the fixture. Clearly, if one recreates the fixtures the test will fail, so I prepared a patch. I find this to be the least hacky way to do it. Also, this makes it quite straightforward to add support for more terminal not included in GNU dircolors in the future. Nevertheless, I think a refactor to accommodate the general case would be preferable. As I wrote in the linked issue, I'm unable to write high quality Rust to do it. I'm fine if this PR is closed, if someone could carry on the refactor to match the GNU behavior for coloring |
we don't mind having differences like this one with GNU. So, it should be directly merged |
Apply the patches to include more terminals that support colors: | ||
|
||
```shell | ||
git apply /PATH_TO_COREUTILS/src/uu/dircolors/alacritty-supports-colors.patch | ||
``` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this step necessary? The change is already applied by this commit, so this instruction is meaningless.
Suggestion: Remove this instruction, and remove the patchfile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is necessary because this README explains how to update the fixtures from the internal database, so the next person who does it should also do this step. Otherwise, the changes will be lost and the tests will fail again next time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would changes in git be lost?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If one updates the test fixtures, why wouldn't they commit the changes? They will, obviously, and this patch would be lost. Therefore, we need to tell them to re-apply it.
It seems quite a simple matter to me. Maybe I'm not expressing myself well, if so, please tell me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible that you didn't notice that the change to the fixture is already in the commit? https://github.com/uutils/coreutils/pull/6725/files#diff-26d0675eb8206b8804aec078728efbfb465417b19b82bf606811a217f9580bc3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know, I made the commit. 😅
Okay. Let me try to explain this with an example.
- Our fellow developer, let's call them Alice, notices something odd in uutils
dircolors
. - They make some changes to fix the behavior.
- At this point, they want to run the tests to make sure they didn't break anything.
- Alice is a fan of
dircolors
and knows that a new version of the GNU counterpart has just been released. - They recall seeing the README of uutils
dircolors
, titled "How to update the internal database". - Since a new release of GNU
dircolors
is out, they decide to follow the steps to update the test fixtures. - Now, they run the tests and... A test is failing!
- However, it is not Alice's fault; their code did not actually break anything.
So why did a test fail? The problem is that, at step 6, Alice updated the test fixtures overwriting the patch that adds Alacritty to the list of terminals that support colors.
Conclusion: We should tell Alice to apply the patch every time they regenerate the test fixtures. Also, we kindly provide them the patch file.
Any value of
TERM
with glob patternalacritty*
will be matched.Note that a more comprehensive approach may be needed to fix the problem in the general case, with a more faithful implementation with respect to the GNU coreutils
ls
. See the discussion on the related issue for more details.Fixes #6722