upvote

points

by vdombr7 hours ago |
comments
upvoteby greyw7 hours ago|
[-]
[flagged]
reply
upvoteby ninjin7 hours ago|
parent|
next
[-]
"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.
reply
upvoteby mahboi6 hours ago|
parent|
next
[-]
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.
reply
upvoteby jonhohle5 hours ago|
parent|
next
[-]
The GNU versions work fine in macOS. Apple doesn’t want to distribute them, but that’s mean you can’t use them.
reply
upvoteby duskwuff3 hours ago|
parent|
next
[-]
> Apple doesn’t want to distribute them

Apple can't distribute them - coreutils is GPLv3, which is incompatible with Apple's immutable system volume.

reply
upvoteby Kwpolska2 hours ago|
parent|
[-]
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?
reply
upvoteby duskwuff1 hours ago|
parent|
next
[-]
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.

https://www.gnu.org/licenses/gpl-3.0.en.html#section6

(There are other issues with GPLv3 which make it a dubious choice for companies like Apple, but this one is particularly problematic.)

reply
upvoteby mahboi2 hours ago|
parent|
prev|
[-]
This isn't new, GPLv2 is somehow compatible. This is the entire reason Mac OS ships an old version of bash but recent git.
reply
upvoteby mahboi4 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby collinfunk5 hours ago|
parent|
prev|
[-]
> 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.

[1] https://portal.cfarm.net/

reply
upvoteby thesuitonym3 hours ago|
parent|
prev|
next
[-]
POSIX compliance doesn't buy you anything because you're trying to use GNU extensions, which aren't in POSIX.
reply
upvoteby mahboi3 hours ago|
parent|
[-]
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.
reply
upvoteby frumplestlatz5 hours ago|
parent|
prev|
next
[-]
If you stick to POSIX, things generally work everywhere. It's not really a question of what is better, just what is portable.
reply
upvoteby mahboi3 hours ago|
parent|
[-]
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.
reply
upvoteby Y_Y4 hours ago|
parent|
prev|
[-]
Sounds like it's Apple who's behind
reply
upvoteby mahboi4 hours ago|
parent|
[-]
In some cases they are, but that's not the cause for the mismatch vs GNU.
reply
upvoteby greyw7 hours ago|
parent|
prev|
next
[-]
Thats exactly what I mean. I dont care about Posix or the whining about "anti-features". The BSD stuff is a clear subset that doesnt get the job done.

Posix is more an art form documenting the far gone past rather than a practical tool

reply
upvoteby Calavar6 hours ago|
parent|
next
[-]
What are some GNU coreutil extensions that you find you can't live without?
reply
upvoteby LtWorf6 hours ago|
parent|
[-]
The conventions for the long parameters on the command line.
reply
upvoteby pjmlp3 hours ago|
parent|
prev|
next
[-]
Dunno, since learning Xenix in 1993, I got plenty of work done in UNIX clones.
reply
upvoteby ninjin7 hours ago|
parent|
prev|
[-]
"[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.
reply
upvoteby thomashabets25 hours ago|
parent|
prev|
[-]
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.

reply
upvoteby 0c3ca836 hours ago|
parent|
prev|
next
[-]
That's kind of like saying that the MacOS UI can't even keep up with Microsoft Windows. Who wants inconsistent GNU halfassery?
reply
upvoteby Quitschquat7 hours ago|
parent|
prev|
[-]
I think that's a cultural thing in *BSD.
reply