"Can't even match GNU's coreutils"? Care to elaborate? Last time I checked OpenBSD is pretty much in line with Posix and there are plenty of us that consider many of the GNU extensions to be anti-features.
I use a Mac, so the CLIs are the BSD versions. I don't have any opinion on which is better, but it's just annoying that it's different from GNU, so a lot of my work ends up being on a Linux VM or server instead. POSIX compliance doesn't seem to buy me anything. I like the BSD license though.
That's a brand new excuse, Apple refused to distribute GPLv3 when GPLv3 was first published, 20ish years ago. How is GPLv3 incompatible with their system volume, yet GPLv2 is still fine?
GPLv3 added language which specifically requires that GPLv3 software embedded in products be distributed with "Installation Information" explaining how modified versions of that software can be installed. It is not at all clear how this would apply to software in an immutable, signed system volume. This language was not present in GPLv2.
You're entitled to your opinion, but that doesn't change the fact that the situation is "Apple can't distribute them", not "Apple doesn't want to distribute them".
Continuing to "correct" "want" to "can't" doesn't make sense, even under your interpretation of the situation. Even assuming the GPLv3 requires all software on the machine to ship under a compatible license (it doesn't), they can do that. They don't want to.
Of course, but any script meant for Mac is going to assume Mac core utils, even assume zsh instead of bash. You don't want to be the one person on the team with a non-stock setup.
> The GNU versions work fine in macOS. Apple doesn’t want to distribute them, but that’s mean you can’t use them.
We also test GNU coreutils on macOS. It is a bit tricky since the other maintainers and I don't own any macOS machines for testing. But we seem to do well enough with a shared system that Adélie Linux kindly allows the compile farm [1] to use, along with some additional CI machines.
I don't know how compatible my Mac will really be with a Free/OpenBSD machine. Last time I tested this theory, some C code I was building on Mac clang didn't build on FreeBSD clang cause I was unknowingly using some extension enabled by default. But that was about 12 years ago.
I'm not trying to. And it's not even like GNU/Linux/whatever is a superset of POSIX and I'm using the extensions. There are mutual differences in basic functionality.
"[Doesn't] get the job done"? Well, it gets my job done. You are welcome to use whatever you subjectively prefer (I use GNU's date(1) for a few scripts, but would prefer the English date grammar parsing as a tool of its own), but if you are unable to talk about anything in concrete terms there is not point in trying to discuss in good faith and I will just roll my eyes and move on.
I am not the parent commenter, but I have the same sense that the GNU ones are better.
But the only concrete example I can think of is that `cat -n a b`, if `a` doesn't end in a newline, produces something that is obviously not what the user wanted. GNU cat does it right.
I didn't report it to the openbsd people because I didn't want them to yell at me that `-n` is nonstandard anyway with no "right" behavior, so I should STFU. Which would be what I'd expect from having reported problems in the past.
I think the behavior in the GNU clone is more consistent with "we added line numbers to the concatenation tool" while whoever added it to OpenBSD's ancestry was probably more concerned with generating listings for printing.
Personally, I'd remove even the POSIX [-u] flag from all cat versions because all of them are un-UNIX-like.
Some GNU tools are particularly ridiculous with the Easter egg features I only know about because LLMs use them all the time —and I have been using Linux for 30 years.
Because you don't like the design(I don't either) but it carries information.
Someone could have thought it was a good idea and no one was willing to audit all of UCB's scripts to fix the "bug" even if it had been the result of a lazy implementation because ed(1) on a terminal.
My choice of wording is from my assumption that nobody, at any point, actually wanted that behaviour. And I stand by that being a pretty safe bet.
So I wouldn't refer to it as "the design". It's not that the methods are unsound, it's that I don't see any method at all.
As for not wanting to break existing scripts, OpenBSD is not even remotely as concerned about backwards compatibility as Linux is. I don't mean that in a derogatory way. It's a perfectly cromulent choice.
