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

feat: permissions only as numbers #889

Open
tcurdt opened this issue Mar 10, 2024 · 4 comments
Open

feat: permissions only as numbers #889

tcurdt opened this issue Mar 10, 2024 · 4 comments

Comments

@tcurdt
Copy link

tcurdt commented Mar 10, 2024

while the usual display of permissions as .rw-r----- is nice and dandy,
for some it might be shorter and clearer to see the actual number.

.rw-r----- => 0640

That would be nice feature to have a concise and easy to read display.
And there already is

eza -la --octal-permissions
0640 .rw-r----- 128 root 10 Mar 15:30 foo.env

But why does it print both? I only want to see the octal permissions.

@Delapouite
Copy link

I agree this is not intuitive at the moment, but you can achieve what you want with:

eza -la --octal-permissions --no-permissions

That said, the --no-permissions flag may need to be renamed to something less ambiguous.

@ShadiZade
Copy link

I would add that the octal permission numbers should be in different colors, not one uniform color as it is now. For example, in 0644, the 0 could be white, the 6 purple, and the 4s yellow. This would make it much easier to read (and just plain nicer), and would accord with the colors of the full .rw-r----- permission format.

@tcurdt
Copy link
Author

tcurdt commented Mar 12, 2024

I am not opposed but - careful. Colors should be very subtle then.
This needs testing or should be started as optional.

Too much color can also have the opposite effect of what was intended.
At least that is what UX teaches.

@MartinFillon
Copy link
Contributor

That said, the --no-permissions flag may need to be renamed to something less ambiguous.

You got a point here. This could be looked at after #787 is merged so that we got the new parser

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

4 participants