// 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);
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'.
// 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);
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'.
It was just a quick solution showing how to do it with one macro and zero dependencies, utilizing the power of meta variables. It probably can be made nicer.
Side Note: It's not directly relevant/needed here, but this also shows that maybe a theoretical $reverse{} meta variable can be useful with repeated patterns, to in this case generate the variants in the expected order.
The most relevant part of the curl project is the library, not the CLI tool. And its biggest advantages in addition to universal availability is support for many protocols other than HTTP, flexible interface(s), two useful well-documented and largely stable APIs (one wraps the other for easy use), multiple TLS/SSL back-end support, and finally, the complete(ish) HTTP protocol support. But that last one alone is not that big of a deal. libcurl's implementation even uses external libraries for both HTTP2 and HTTP3 for framing. It uses an external library for QUIC transport support too. Meanwhile, many other independent language implementations for HTTP exist that range from serviceable to complete. Be it Python, Go, Rust, or many others, you usually get a "native" option you could/should use. Gone are the days of bad old PHP. Hell, even some WIP languages add usable native implementations sometimes as a part of their standard libraries, like inko.
Within the Rust ecosystem, you're fully covered by hyper. Even very obscure HTTP features like obsolete HTTP1 multi-line headers are supported (you have to enable this one explicitly). And I only know this because I had the fortunate circumstance of coming across a server that used these (It was an educational, if interesting, couple of afternoon hours).
This, and similar posts discussing the same subject, seem to fail to realize that you can trivially implement your own back-off strategy using Mutex::try_lock(). This can have significant performance implications in use-cases where absolute low latency is not required.
I rarely see this get mentioned, although I think I did see it once or twice.
A shout out to the spin crate too, which has a lot of options that may interest people explicitly supported/exposed. It also supports no_std which can be immensely useful in some use-cases.
And you do know that the docs.rs service itself generates docs from published crates in crates.io, and that is the exactly same code you see when viewing sources there, right?
Reading your comment, I immediately thought there must be an S3 FUSE wrapper out there, and quickly found this:
https://github.com/s3fs-fuse/s3fs-fuse
I didn't realize this was posted here.
Allow me to copy my comment from another thread:
This is not rustic, I feel.
is more like it.
From there, you can
next()for first error,last()for last error, orfold()for max error, orcollect()if you need to save all errors.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'.This is not rustic, I feel.
is more like it.
From there, you can
next()for first error,last()for last error, orfold()for max error, orcollect()if you need to save all errors.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'.It was just a quick solution showing how to do it with one macro and zero dependencies, utilizing the power of meta variables. It probably can be made nicer.
Side Note: It's not directly relevant/needed here, but this also shows that maybe a theoretical
$reverse{}meta variable can be useful with repeated patterns, to in this case generate the variants in the expected order.(slightly edited from initial version)
I have the feeling that this wasn't even done properly (e.g. checking default versions only). Using downloads alone is also not a good filter.
I may give this some time tomorrow and provide my own numbers.
The most relevant part of the curl project is the library, not the CLI tool. And its biggest advantages in addition to universal availability is support for many protocols other than HTTP, flexible interface(s), two useful well-documented and largely stable APIs (one wraps the other for easy use), multiple TLS/SSL back-end support, and finally, the complete(ish) HTTP protocol support. But that last one alone is not that big of a deal.
libcurl's implementation even uses external libraries for both HTTP2 and HTTP3 for framing. It uses an external library for QUIC transport support too. Meanwhile, many other independent language implementations for HTTP exist that range from serviceable to complete. Be it Python, Go, Rust, or many others, you usually get a "native" option you could/should use. Gone are the days of bad old PHP. Hell, even some WIP languages add usable native implementations sometimes as a part of their standard libraries, likeinko.Within the Rust ecosystem, you're fully covered by
hyper. Even very obscure HTTP features like obsolete HTTP1 multi-line headers are supported (you have to enable this one explicitly). And I only know this because I had the fortunate circumstance of coming across a server that used these (It was an educational, if interesting, couple of afternoon hours).This, and similar posts discussing the same subject, seem to fail to realize that you can trivially implement your own back-off strategy using
Mutex::try_lock(). This can have significant performance implications in use-cases where absolute low latency is not required.I rarely see this get mentioned, although I think I did see it once or twice.
A shout out to the
spincrate too, which has a lot of options that may interest people explicitly supported/exposed. It also supportsno_stdwhich can be immensely useful in some use-cases.You know repository info is just metadata, right? You can set it to anything.
And you could have grabbed the actually published versions easily, before randomly fear mongering against a random forked crate.
Run this for both crates, and you will have these crates locally at:
from there
And you do know that the
docs.rsservice itself generates docs from published crates incrates.io, and that is the exactly same code you see when viewing sources there, right?Do you mean a global allocator?