I didn't realize this was posted here.

Allow me to copy my comment from another thread:

// Don't bail on the first error, but remember the worst one.
let mut worst = 0;
for file in files {
    if let Err(e) = chmod_one(file) {
        worst = worst.max(e.exit_code());
    }
}
process::exit(worst);

This is not rustic, I feel.

files.iter()
  .map(chmod_one)
  .filter_map(Result::err)

is more like it.

From there, you can next() for first error, last() for last error, or fold() for max error, or collect() if you need to save all errors.

And no, static compilation doesn’t help here, because get_user_by_name goes through NSS, which dlopens libnss_* modules at runtime regardless of whether your binary is statically linked.

This is not true in musl systems. I just quickly checked in a Chimera rootfs (which has a system dynamic musl libc btw).

I believe the described dlopening is one of the well known reasons why GNU libc is not suitable for static linking, unlike musl!

In Arch, this indeed loads /usr/lib/libnss_systemd.so.2.

Everyone can test this with strace id 2>&1 | egrep 'open.*\.so'.

I was very confused by this sentence until I realized it's a programming thingy.

I'm not a rust programmer, can anyone with experience in systems programming explain a legitimate use case for the uutils other than weakening the GPL? The auther even admits that several coreutils are still GNU in 26.04 which begs one to ask "why the rewrite?"

This is an excellent article that breaks down common pitfalls and provides really concise rules for avoiding them. It's a great read if you're in to systems programming.

As someone who is not at all into programming, this title made me genuinely think I had a stroke.

Those are bugs I dont think any programming language catch, unless it's a DSL for writing such programs on Linux or another OS.

Another stupendous reason to gpl uutils so that the decades of experence of hundreds of system programmers can be leveraged in the rewrite.