GNU testsuite comparison:

Skip an intermittent issue tests/misc/usage_vs_getopt (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/misc/stdbuf (passes in this run but fails in the 'main' branch)

How should we test the situation where UID != EUID or GID != EGID? I had the idea of mocking the State struct, but the id_print function is hard to test as it only prints to stdout. Also, it uses the Passwd::locate and Group::locate functions internally, meaning even if we could mock the State struct, the tested UIDs and GIDs should be valid on the system for the test to work.

Could you please add a test to make sure we don't regress in the future?
Thanks

Yes, I can. I will probably try to mock the getuid, geteuid, getgid, and getegid functions for the tests. I will return to this probably later today.

i don't think you need to do that, you should do that in
https://github.com/uutils/coreutils/blob/main/tests/by-util/test_id.rs

I still don't understand how to run the command so that the UID != EUID or GID != EGID without somehow mocking them.

@sylvestre Did you have any ideas on how this could be tested?

I added a test for different UID and EUID. I didn't figure out a better way than to overwrite the getuid and geteuid functions using the LD_PRELOAD environment variable. Please let me know if you see any issues with this, or if it is not the preferred way of testing this.

@tertsdiepraam The original issue requires elevated privileges and assumes that a system has id installed, which it most likely has. A simpler way to test would be to use setuid and setgid if we were to create a test that requires elevated privileges anyway. There are quite a few tests that use the run_ucmd_as_root function, but it does not work in this case, because if we run id as root, both UID and EUID will be 0.

In my opinion, creating a test that requires elevated privileges as a precondition is not a good idea if there are no other tests that do so, except those that use the run_ucmd_as_root function. If we were to leave the current test as is, gcc could be changed to cc for better portability. It could also be removed if you want.

The current test also does not break if a system does not have the cc command available, as the unwrap_or_return macro exits gracefully if the command does not work. It should only fail if the compiler exists, but the compilation fails somehow.

I'm open to any decision you make.

GNU testsuite comparison:

GNU test failed: tests/misc/tee. tests/misc/tee is passing on 'main'. Maybe you have to rebase?
Skipping an intermittent issue tests/misc/stdbuf (passes in this run but fails in the 'main' branch)

@tertsdiepraam The test doesn't work on CI/CD, so I guess it should be removed. What would you like me to do? Should I remove the test, or also try to do a test that requires elevated privileges as a precondition?

I'm ok with no test, but I'll defer to @sul. Maybe he has some ideas

GNU testsuite comparison:

Skipping an intermittent issue tests/misc/usage_vs_getopt (passes in this run but fails in the 'main' branch)

Feel free to merge as is. Please let me know if you have any ideas on how the testing could be performed.