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

[mtalexan]

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]

@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]

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.

[ferki]

I, for one, also often miss group ownership info when using -l, especially given that the permission info is fully printed — I'm told what the group members may or may not do, but I have no clue which group is that 🤷

That feels inconsistent as user experience.

[tcurdt]

I am OKish not showing the group if it's the same as the user but this here is just a pretty bad UX:

# eza -l
.rw-r----- 128 root 10 Mar 15:30 foo.env
# eza -lg
.rw-r----- 128 root foo 10 Mar 15:30 foo.env

If user != group it should never be hidden (unless I asked it to).

[Omnikron13]

I think that's the crux of the issue here really; number 2 is actually ideal most of the time because it just prevents alice alice or w/e cluttering the output, but when there actually is a difference you're potentially much more likely to be interested in knowing about it.

I think potentially there's a possibility of actually improving on the output of ls -l by printing out alice ??? (I'm not sure what exactly) instead of alice alice, and then the alice aruba listing (or w/e) stands out even more.

Would of course require a little examination of the files to see if the group column is actually adding any information before printing, but I'd say that's worth it to provide more information at a glance to the user imo.

[tcurdt]

Maybe we can remove the bias from the discussion?

I already understood, that you think 2. is ideal - for you.
I'd challenge the "most of the time" and very much disagree.

It seems like 4 could be a compromise:

username could be username username
username* could be username groupname-is-different-from-username

But even that would not make a sensible default for an OPS minded person.
So I guess the background of the user matters.

[Omnikron13]

I'm perhaps not expression what I mean very well... I specifically mean that if every entry that is being printed out has identical user and group data, then it's superfluous to actually print them both out. I agree it's clearly an unintuitive and misleading problem if any files in the output aren't identical, and the extra column really ought to be there as would be expected coming from ls.

A more elegant and readable solution might be to either use colour, an icon, something like username* when they do match, or to fill the empty column in some way like steven [....] perhaps? Unless the intention is process the output in some way this is perhaps an issue, though I've been operating under the assumption that this is not the primary use case of eza.

If this was the behaviour it would be pretty quick and easy to see if any non-matching files were output, and to find them in the list as they would have properly filled columns there.

I'd challenge the "most of the time" and very much disagree.

This getting a little tangential really from the possible solutions here, but I suppose we can't really expect some degree of bias to not creep into such things, and can't be unbiased without looking at how frequently directories contain files with non-matching username/group children, and how often people are using the long output in those directories vs. others.

[mtalexan]

It seems a lot of thought and work is going into avoiding printing both the user and group columns when they're the same name.
It should probably be pointed out that only about half of Linux distros assign a matching group name, and only to locally created users at that. If you have an SSO/LDAP/Active Directory user, they're usually assigned to a fixed group (i.e. domain-users). If you have a server version of basically any distros, it also assigns locally created users to a fixed group (i.e. users). If you're running a desktop version of one of the other 50% of distros, it also assigns local users to a fixed group (i.e. users).

So a lot of time and energy is being put into avoiding showing a duplicate of the name when only Desktop installs of some distros for a local user even fit that case.

[tcurdt]

I suppose we can't really expect some degree of bias

Agreed - but then it should maybe not act as the main argument. It's better to concentrate on more tangible points.

This is problematic from a UX POV (and IMO should not be the default)

drwxr-xr-x     - tcurdt 2024-01-09 18:33 shells
drwxr-xr-x     - tcurdt 2024-03-09 13:33 users

This gives the expected information (but some -not me- might consider it verbose)

drwxr-xr-x     - tcurdt staff  2024-01-09 18:33 shells
drwxr-xr-x     - tcurdt tcurdt 2024-03-09 13:33 users

This might be a middle ground:

drwxr-xr-x     - tcurdt* 2024-01-09 18:33 shells
drwxr-xr-x     - tcurdt  2024-03-09 13:33 users

[Omnikron13]

This is problematic from a UX POV (and IMO should not be the default)

drwxr-xr-x     - tcurdt 2024-01-09 18:33 shells
drwxr-xr-x     - tcurdt 2024-03-09 13:33 users

Yeah this is really not acceptable for in the case of this data set.

This gives the expected information (but some -not me- might consider it verbose)

drwxr-xr-x     - tcurdt staff  2024-01-09 18:33 shells
drwxr-xr-x     - tcurdt tcurdt 2024-03-09 13:33 users

Well, it is certainly displaying rather redundant information that could be inferred, especially compared to this counter example date, where actual variances may get lost in the noise.

drwxr-xr-x     - tcurdt tcurdt  2024-01-09 18:33 shells
drwxr-xr-x     - tcurdt tcurdt  2024-03-09 13:33 users
drwxr-xr-x     - tcurdt tcurdt  2024-05-09 08:33 other
drwxr-xr-x     - tcurdt tcurdt  2024-05-09 03:33 things

This might be a middle ground:

drwxr-xr-x     - tcurdt* 2024-01-09 18:33 shells
drwxr-xr-x     - tcurdt  2024-03-09 13:33 users

This would definitely display a bit more information, but not really the specifics you might want to know;...

Un-hiding to the column but indicating it contains the same data would seem to be more conducive to quickly reading the output. Something more like this:

drwxr-xr-x     - tcurdt staff   2024-01-09 18:33 shells
drwxr-xr-x     - tcurdt   ~     2024-03-09 13:33 users
drwxr-xr-x     - tcurdt   ~     2024-05-09 08:33 other
drwxr-xr-x     - tcurdt   ~     2024-05-09 03:33 things

(The actual character, or icon, or characters, colour, etc. standing in for the repetition would have to have more thought put into it ofc. Or be declared by themes tbh.)

[tcurdt]

If keeping the column is fine, I don't really get the point of replacing the group with a "same" indicator.
I'd be OK with it - but I don't think it really helps. I would just show the group by default and be done with it.