5 ms·
Rust clean-slate POSIX CLI utilities 0.2.1 release: Awk, M4, ftw and more
- nialv7 2y agoShould've called it Oreutils.
- deleted 2y ago[deleted]
- rybosome 2y agoI’d love to see what performance benchmarks look like. The old ones were highly optimized, but perhaps for different challenges than today’s architectures present.
- simonask 2y agoWould definitely be interesting, but from a cursory look at the repository, it doesn't look like squeezing the last percentage points of performance has been a priority yet. Things that stand out: - The `awk` implementation uses the Pest parser generator (https://pest.rs/ https://pest.rs/), which is known to not generate the fastest possible parsers, but is great for getting up and running. - They are using the `clap` crate for argument parsing, which is also known to not be the fastest, but again is very user friendly (for example, it does Unicode linebreaks in the output of `--help`). It's marginal, but for a tiny utility being invoked many times from a shell script, this can add up. It's very probably "fast enough", and it makes sense to prioritize like this at this point, but people shouldn't use this expecting a performance improvement right now.
- littlestymaar 2y agoYeah, and I don't think performance matters that much for these utilities (and AFAIK many of the original haven't been particularly optimized for performance anyway).
- dundarious 2y agoCheck the list, performance matters a great deal for many of these utilities, and the GNU project version is often pretty well optimized (often best in class of POSIX compliant impls that ship with an OS/distribution). I do not want a "performance will be looked at later" version of m4, awk, grep, cp, find, diff, sort, uniq, etc., right now in my personal or dev environments. I can understand using a not-yet-optimized memory safe language version to compete with OpenBSD though, but not for me right now.
- littlestymaar 2y agoYou are already using “performance will be looked at later” versions of grep and find as they are much slower than alternative implementations (ripgrep and fd are way faster) and these are the one for which perf is the most sensitive in your list… The fact that performance don't really matter for these tools in the general case is the reason while most people still stick with those slow POSIX-compliant tools when much faster alternatives exist. (POSIX-compliance only matters when using it in existing scripts, but not at all when using it in the command line or when writing new scripts)
- kazinator 2y agoPOSIX compliance totally matters for interactive use, too, if POSIX is what you know. That's like saying English only matters if you're revising some existing paper written in English, but if you're writing something new or conversing with somebody face to face, then English doesn't matter at all. Sure unless English is your most proficient or perhaps only language. The GNU project didn't have to implement Unix compatible utilities. They were starting with a blank slate and could have implemented anything. Why did they choose the compatible route? Because it matters. People were able to replace proprietary Unix programs with GNU programs without disrupting their workflows or having to learn anything (unless they were curious about GNU extensions).
- wmf 2y agoI didn't realize The Open Group still exists and is updating POSIX.
- jgarzik 2y agoUpdated in 2024, no less! (2024 version still has UUCP though, heh)
- 7bit 2y agoI always wondered, is there an actual POSIX documentation or spec out there? The last time I researched it, it seemed that POSIX is a number of documents behind a massive paywall. Yet, so many people seem to know what is and isn't POSIX compliant, that it just seems unlikely that POSIX is locked behind a paywall.
- teo_zero 2y agoI like standards and abhor bloat, but I must admit there are GNU extensions that are so useful and well known that it would be difficult to do without. Probably this happens when POSIX specs are too strict or feature-poor to be of use even for medium-complexity tasks. One example is "make": I'm afraid that a POSIX-only implementation wouldn't run most Makefiles out there!
- marcus0x62 2y agoThey acknowledge this. From the project's README.md: > Popular GNU options will be supported by virtue of the "don't break scripts" rule. Unpopular options will not be implemented, to prevent bloat.