The function `get_current_uid` returns a `uid_t` value representing the user currently running the program, and the `get_user_by_uid` function scans the users database and returns a User object with the user’s information.
This function returns `None` when there is no user for that ID.
This code assumes (with `unwrap()`) that the user hasn’t been deleted after the program has started running.
For arbitrary user IDs, this is **not** a safe assumption: it’s possible to delete a user while it’s running a program, or is the owner of files, or for that user to have never existed.
So always check the return values from `user_to_uid`!
There is also a `get_current_username` function, as it’s such a common operation that it deserves special treatment.
While a short program may only need to get user information once, a long-running one may need to re-query the database many times, and a medium-length one may get away with caching the values to save on redundant system calls.
For this reason, this crate offers a caching interface to the database, which offers the same functionality while holding on to every result, caching the information so it can be re-used.
This cache is **only additive**: it’s not possible to drop it, or erase selected entries, as when the database may have been modified, it’s best to start entirely afresh.
So to accomplish this, just start using a new `OSUsers` object.
You should be prepared for the users and groups tables to be completely broken: IDs shouldn’t be assumed to map to actual users and groups, and usernames and group names aren’t guaranteed to map either!
Use the mocking module to create custom tables to test your code for these edge cases.
# Mockable users and groups
When you’re testing your code, you don’t want to actually rely on the system actually having various users and groups present - it’s much better to have a custom set of users that are *guaranteed* to be there, so you can test against them.
This sub-library allows you to create these custom users and groups definitions, then access them using the same `Users` trait as in the main library, with few changes to your code.
## Creating mock users
The only thing a mock users object needs to know in advance is the UID of the current user.
Aside from that, you can add users and groups with `add_user` and `add_group` to the object:
The exports get re-exported into the mock module, for simpler `use` lines.
## Using mock users
To set your program up to use either type of Users object, make your functions and structs accept a generic parameter that implements the `Users` trait.
Then, you can pass in an object of either OS or Mock type.