> Why don't sed, awk, grep, etc.. all the Linux things work quite right? I need to add something else on macOS to get them to work like they did on Linux.
If you mean how they work, like command line arguments and such (and not just speed), that's because macOS is based on BSD and thus using the BSD and not GNU versions. That's not really a "not right" thing, it's just different, and would be the same if you used any other BSD like OpenBSD, FreeBSD, etc.
If you install GNU coreutils from Nix (and maybe some other package managers, idk) you can get them with their normal PATHs, at the cost of some possible incompatibility with macOS-specific scripts that assume the bundled versions.
I used GNU ones without the `g` prefix for a year or two and never ran into trouble because of it.
no, it's definitely "not right" -- mac os ships with ancient, crippled versions of the bsd utilities, afaict simply because it's bad for open source and because they can. E.g. `man sed` then check the date at the bottom
I'll bite and talk about centos, the 'stable' distro.
Take the example of 'tar' that slowly evolved and some time even changed its default behaviour. e.g. what to do when untaring a folder but there's already a symlink with the same name as the folder, do you erase the symlink and create a folder or do you untar the folder in the symlink? Between centos 5 and 7 this changed... Causing me some amount of pain.
hostname stopped supporting '_' in host names. Could have raised a warning, have added a '-pedantic' option but no.
hostname stopped assigning the permanent host name with the 'hostname myhostname' command and now you need to use hostnamectl. Could have left the 'old' feature and make hostnamectl whine instead, but no.
ifconfig the deprecated tool subtly changed the order of fields too and now the MAC address is not in the same place as before, breaking scripts that trusted that not to change.
df changed its syntax, adding or removing a new-line some time ago.
Yeah thinking back we shouldn't have used the standard tools and expected them not to change.
So, now, whenever I see in code review some bash person using 'standard' tools to get info that could be gathered through procfs or sysfs, I instead ask they use procfs, sysfs or ioctls and be done with it.
To be fair, the last two are more from a bad design choice by *nix in general to base everything on passing around unstructured text and hoping each tool's ad-hoc schema won't change.
That 'hope' was true for some time, I guess. Those systems had no problems with previous migrations from early fedoras to centos 5.9... When your last line of compatibility is procfs and sysfs and ioctls or posix calls (statvfs for free disk space), well I know what Linux devs think of their installed userbase's time. Yeah yeah free stuff for free alright. Still, if you'd paid for rhel, same shit. Thank your dogs we provide an /etc/redhat-release, heh.
And if course even Linux procfs is not without its surprises. Adding columns or lines was foreseen but some changes are more fun!
Take the evolution in /proc/meminfo that changed the meaning of some of the lines there over time (WTF?), whilst adding others (which was fine, expected, etc.). Of course I want now to include IO cache (that will be reclaimed if I ever needed to malloc) in my system's free memory indicator! Heh you can still get back the old value with this formula, what are whining about?
If you mean how they work, like command line arguments and such (and not just speed), that's because macOS is based on BSD and thus using the BSD and not GNU versions. That's not really a "not right" thing, it's just different, and would be the same if you used any other BSD like OpenBSD, FreeBSD, etc.