Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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: exa -l doesn't show group info (from exa) #198

Closed
mtalexan opened this issue Sep 6, 2023 · 2 comments
Closed

feat: exa -l doesn't show group info (from exa) #198

mtalexan opened this issue Sep 6, 2023 · 2 comments

Comments

@mtalexan
Copy link

mtalexan commented Sep 6, 2023

From exa Issue: ogham/exa#1118

tl;dr
The ls -l command includes the name of the group that the "group permissions" apply to. This is pretty commonly used info, but requires adding the --group flag to get it now. Please add it back to the default, or make it a customizable default for when -l is used.

@mtalexan
Copy link
Author

mtalexan commented Sep 6, 2023

@ariasuni mentioned in the original Issue report when redirecting here, that they hadn't personally used the group info in the past year.

As a counter point, I've personally used it almost every day for the past year. If you're working with device nodes (/dev), containers, configuring servers, or debugging problems in newer distros (e.g. immutable distros), a missing group membership is often a consideration/factor. Many/most system tools use group ownership of files, folders, sockets, and devices to manage which users have access to use the tools. Installing those system tools, debugging them, or trying to use them within a container means regularly verifying the group on them and comparing it to the groups a user is a member of (especially in containers where the GID may need to be explicitly mapped).
In the context of file ownership, my experience has been that it's only a little less likely you need to know the group as that you need to know the owner of a file.

So the things I personally use the extended info for, in order of frequency, are:

  1. Is it a symlink, folder, file, block device, or character device?
  2. Where does the symlink point?
  3. What are the rwx permissions on the file?
  4. Who's the owner of the file?
  5. What's the group of the file?
  6. How big is the file?
  7. Are there ACL permissions?
  8. When was the file last modified?
  9. What's the major/minor number of the device node?

If you notice, the last modified time is actually one of the least likely things I'm looking for, though I definitely understand that many people use that info a lot more often than I do. Similarly I understand that most people probably check the size of the file way more often than they consider the group.


I think it makes a lot of sense to match the native ls -l behavior in terms of showing the group of a file, the rwx permissions are grouped into 3 sets for user/owner, group, and other, so it's part of the permissions description to know which group that group permission applies to.

@cafkafk
Copy link
Member

cafkafk commented Sep 6, 2023

From exa Issue: ogham/exa#1118

tl;dr The ls -l command includes the name of the group that the "group permissions" apply to. This is pretty commonly used info, but requires adding the --group flag to get it now. Please add it back to the default, or make it a customizable default for when -l is used.

We might make it possible to set a default whenever I have time to look into #139, but until then, perhaps an alias would be sufficient. We could still consider changing the default behavior, but this would probably be better handled by a discussion thread than an issue.

I personally use an alias to get the default eza behavior I need, and I'm cautious about enforcing my overly opinionated takes onto the default user.

That said, I do see where you're coming from, but I'd like to see a wider discussion before moving forward.

@eza-community eza-community locked and limited conversation to collaborators Sep 6, 2023
@cafkafk cafkafk converted this issue into discussion #199 Sep 6, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants