Yeah, there’s no good way to “list all users”.
nis is dead but e.g. PAM/LDAP is very much alive.
(disclosure/credentials: I used to work on FreeIPA/Red Hat IdM.)
I use Path.resolve() regularly when exploring what code does, and it would be more pleasing if there was an easy way to get Paths that start ~/... instead of /home/gerlagh/...
But also, that’s the only context where I ever want to unexpanduser.
so I guess that’s +0.5 from me
Good catch… and yeah Debian does it, too.
And while it feels wrong to use /bin, /usr/bin and similar as homedir (though I guess it’s fine for subdirs of /var, /run and similar… that’s how it is.
If such a function were to be added, one could perhaps make its default behaviour like my original proposal, i.e. only unexpand with respect to the current user.
Everything else could be extended via kwargs, if there is sufficient need for a use case, like support for other users (behaviour if there are many possible candidates), exclusion of well-known non-user dirs like/usr, /bin, etc. … or inclusion of only well known user dirs.
Or … we could just leave it altogether.
Linux distinguishes system accounts and user accounts by UIDs. Don’t know wether it is somehow standardized. On my distro UIDs below 1000 are system accounts. I vaguely remember the limit was 500 long time ago. The actual values are defined in /etc/login.defs, example:
UID_MIN 1000
UID_MAX 60000
When dealing with home directories, you are typically interested in user accounts only. That should be the default overridable by a kwarg.
I think that’s rather a “soft” standardisation… plus it’s more difficult than that (e.g. on Debian).
Obtaining that information would seem rather hacky to me… and that would be Linux alone.
Yes, it is “hacky”, but that’s the reality anyone wanting meaningful output will have to face.
AFAICS, “hacky”, here, really means that we’d probably have to hardcode these lists for each distro.
At least in Debian I already wouldn’t know an machine-readable file which reflects the true UID range reservations.
/etc/adduser.conf merely contains the range that adduser uses, which is however only a portion of the full range(s) that the policy has reserved. Plus adduser is not an essential package thus there’s not even the guarantee that the file would be there.
Similar for login.defs.
One could use Users, Groups, UIDs and GIDs on systemd Systems but that bites any people who don’t use systemd.
Not to talk about the BSDs, Windows or simply any setups who choose to ignore the above conventions.
And all data might even change between versions.
Given that there’s only some slight support for even the simple version of the proposed function, I don’t think it’s realistic that any of the above (heuristics for determining whether system/normal user) would ever finds its way into os or pathlib.
2 Likes