4 ms·
Not shown: the bewildering choices made for various tools. sed * The `-i` flag - In the absence of a file extension given, I should not have to specify with `
by sgarland 4y ago
Not shown: the bewildering choices made for various tools.
sed
* The `-i` flag - In the absence of a file extension given, I should not have to specify with `''` that I want the original file over-written. The flag is called in-place for a reason.
* BSD sed doesn't support ANSI-C escape sequences, so you have to fall back to your shell quoting them for you.
xargs
* Why is there no `-d` flag for BSD?
There are others I've found over the years, but those come to mind as annoyances.
- rrix2 4y agoYeah, BSD coreutils are so frustrating to use...
- 1500100900 4y ago> The flag is called in-place for a reason. What's the reason? Surprisingly, the file is never edited in place.
- sgarland 4y agoOK, I'll give you that the underlying sycscalls are in fact creating a temporary file. But the abstract result to the user is an in-place edit.
- MontyCarloHall 4y agoI agree that BSD coreutils are extremely feature poor (e.g. no PCRE in grep) and have some odd syntax choices as you point out, but you can always install the GNU coreutils. Of course, you then have to prefix everything with “g” (e.g. ggrep, gsed) which can get annoying. That said, this is why I’ve always given up on BSD every time I’ve tried it—all of the low-level technical benefits touted in the article never actually make a difference in my day-to-day usage, whereas little annoyances with the userspace really add up.
- _abox 4y agoThey're just different. It's a different OS. I agree some things don't make sense but some things on Linux don't make sense either. It's just a long heritage of things that have organically grown. Consider 'dd' for example, with its 'if=xxx' whereas other tools would use the format '-if xxx'. But it's a different OS. Solaris tools were different from the GNU toolset. HP-UX' tools were very different (try compiling something on HP-UX CC lol). MacOS' tools are also different. If you expect things to be GNU, use GNU/Linux. Or Hurd :) Or install GNU coreutils.
- sgarland 4y ago> Consider 'dd' for example This is a fair point, and I suppose something I just have grown used to, similar to how I can type `tar xvzf` without any `-` at all, and it works. > MacOS' tools are also different. Tbf when I talk of using BSD tools, I'm talking about using MacOS tools - I don't have any BSD installations, I just recognize that MacOS includes mostly (?) BSD tools by default. I do in fact install coreutils, and either alias them or move PATH priority so they get called first.
- toast0 4y ago> Tbf when I talk of using BSD tools, I'm talking about using MacOS tools - I don't have any BSD installations, I just recognize that MacOS includes mostly (?) BSD tools by default. It's not inaccurate, but somewhat unfair to use MacOS tools and call them BSD tools. They are ports of BSD tools, but Apple rarely refreshes them from the original sources, so it's kind of a time capsule to 2000. If you dropped 2000 era Linux userland on someone today, there would be a lot of complaints and concerns. On some tools, command flags added in GNU coreutils do get added to FreeBSD, although I did not check your list of specifics.
- cpeterso 4y agoIIRC, Apple periodically merges some kernel bits from FreeBSD and user space utilities from NetBSD. (Though I can’t find a source mentioning NetBSD, atm.) I don’t know why Apple would choose NetBSD utilities instead of FreeBSD if they are also using FreeBSD kernel bits. I understand why Apple doesn’t bother to contribute to upstream FreeBSD or NetBSD, but I’m curious why they aren’t eager to merge updates from them more frequently.
- toast0 4y ago> I’m curious why they aren’t eager to merge updates from them more frequently. I suspect it's because the merge isn't easy to do; which is partially a self-fulfilling property of how infrequent it's done, but likely also has a lot to do with the pretty large differences in system design. A lot of the kernel bits are old as heck too; last I checked, at least the Darwin open source kernel doesn't have any protection against syn floods, which FreeBSD first addressed in kernel 4.5 (released January 29, 2002)