I wish env -S was more portable. It's a newer feature of the coreutils env implementation and isn't supported elsewhere afaik.
FreeBSD 6.0 added 'env -S'. They have adopted a few different GNU inspired options recently, which I am happy about.
Readit Newscollinfunk commented on Using Python for Scripting hypirion.com/musings/use-... · Posted by u/birdculture
collinfunk commented on Notes by djb on using Fil-C cr.yp.to/2025/fil-c.html... · Posted by u/transpute
I think that's the build of LLVM+Clang itself.
Yes, linking LLVM takes up a lot of memory. The documented guidance is to allow one link job per 15 GB of RAM [1].
[1] https://llvm.org/docs/CMake.html#frequently-used-llvm-relate...
collinfunk commented on Hard Rust requirements from May onward lists.debian.org/debian-d... · Posted by u/rkta
https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/sr...
I beg to differ.
A lot of the complexity is to handle localized date formats on systems that support them. Most other implementations of 'date' do not do this.
The easiest way to see this is in US locales, which use 12-hour clocks in GNU 'date' but not other implementations:
$ date -d '13:00'
Sat Nov 1 01:00:00 PM PDT 2025
$ uu_date -d '13:00'
Sat Nov 1 13:00:00 2025
[1] https://github.com/coreutils/coreutils/commit/1066d442c2c023...
collinfunk commented on Hard Rust requirements from May onward lists.debian.org/debian-d... · Posted by u/rkta
> Or change / improve the status [quo]
uutils/coreutils is MIT-licensed and primarily hosted on GitHub (with issues and PRs there) whereas GNU coreutils is GPL-licensed and hosted on gnu.org (with mailing lists).
EDIT: I'm not expressing a personal opinion, just stating how things are. The license change may indeed be of interest to some companies.
2 GNU coreutils maintainers, including myself, monitor the issues and PRs on a GitHub mirror that we have [1]. Generally the mailing list is preferred though, since more people follow it.
I think he means POSIX. Didn’t check but in some cases posix only covers some options a tool provides not all. It’s a hard lesson I learned while keeping shell scripts portable between Linux and macOS.
Yep. I was slightly incorrect in my original message, though. SUSv2 (1997) specified egrep and fgrep but marked them LEGACY. POSIX.1-2001 removed them.
The only place that that doesn't support 'grep -E' and 'grep -F' nowadays is Solaris 10. But if you are still using that you will certainly run into many other missing options.
[1] https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.ht... [2] https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.ht...
In some cases it was possible to crash (overflow) sort.c, not just DoS. I did try to look more info the issue - it was not handled for quite some time however I did not find any real world impact.
Minor correction, but that bug was never in any "official" coreutils release. The bug was in a multi-byte character patch that many distributions use (and still use). There have been other CVEs in that patch [1].
But the worst you can do is crash 'sort' with that. Note that uutils also has crashes. Here is one due to unbounded recursion:
$ ./target/release/coreutils mkdir -p `python3 -c 'print("./" + "a/" * 32768)'`
Segmentation fault (core dumped)
You don't attack coreutils. You attack the scripts. In this case it was an update script that failed because of an incompatibility. It's not too hard at all to imagine one failing in an exploitable way.
Honestly, Rust-related hilarity aside, this project was a terrible, terrible idea. Unix shell environments have always been ad hoc and poorly tested, and anything that impacts compatibility is going to break historical code that may literally be decades old.
See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.
> See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.
The 'fgrep' and 'egrep' didn't throw errors, it would just send a warning to standard error before behaving as expected.
Those commands were never standardized, and everyone is better off using 'grep -F' and 'grep -E' respectively.
collinfunk commented on A years-long Turkish alphabet bug in the Kotlin compiler sam-cooper.medium.com/the... · Posted by u/Bogdanp
As a Turkish speaker who was using a Turkish-locale setup in my teenage years these kinds of bugs frustrated me infinitely. Half of the Java or Python apps I installed never run. My PHP webservers always had problems with random software. Ultimately, I had to change my system's language to English. However, US has godawful standards for everything: dates, measurement units, paper sizes.
When I shared computers with my parents I had to switch languages back-and-forth all the time. This helped me learn English rather quickly but, I find it a huge accessibility and software design issue.
If your program depends on letter cases, that is a badly designed program, period. If a language ships toUpper or a toLower function without a mandatory language field, it is badly designed too. The only slightly-better option is making toUpper and toLower ASCII-only and throwing error for any other character set.
While half of the language design of C is questionable and outright dangerous, making its functions locale-sensitive by all popular OSes was an avoidable mistake. Yet everybody did that. Just the existence of this behavior is a reason I would like to get rid of anything GNU-based in the systems I develop today.
I don't care if Unicode releases a conversion map. Natural-language behavior should always require natural language metadata too. Even modern languages like Rust did a crappy job of enforcing it: https://doc.rust-lang.org/std/primitive.char.html#method.to_... . Yes it is significantly safer but converting 'ß' to 'SS' in German definitely has gotchas too.
> While half of the language design of C is questionable and outright dangerous, making its functions locale-sensitive by all popular OSes was an avoidable mistake. Yet everybody did that. Just the existence of this behavior is a reason I would like to get rid of anything GNU-based in the systems I develop today.
POSIX requires that many functions account for the current locale. I'm not sure why you are blaming GNU for this.
collinfunk commented on Show HN: ut – Rust based CLI utilities for devs and IT github.com/ksdme/ut... · Posted by u/ksdme9
uutils/coreutils has a `base64` in Rust which just gained better performance due to the base64-simd crate for SIMD: https://github.com/uutils/coreutils/pull/8578
Note that uutils does not work if the file does not fit into memory.
With GNU coreutils:
$ base64 /dev/zero | head -c 1 | wc -c
1
BSD wasn’t under an open license when GNU got started, so GNU reimplemented the proprietary UNIX utilities with their own enhancements and their own GPL license.
As such, complaining about the license is rich, considering GNU basically stole it themselves from the first round. And to this day, HN complaining about macOS’s utilities is also rich considering they are actually more standard and authentically UNIX than GNU.
https://github.com/apple-oss-distributions/text_cmdshttps://github.com/apple-oss-distributions/system_cmdshttps://github.com/apple-oss-distributions/file_cmdshttps://github.com/apple-oss-distributions/adv_cmdshttps://github.com/apple-oss-distributions/shell_cmdshttps://github.com/apple-oss-distributions/misc_cmds