What version of coreutils? Try comparing the behavior of cp on macOS vs. a modern Linux distribution. They are very different.
I'm not saying Python isn't without its problems too. I don't even like using Python that much for scripting. But we should be clear about what tradeoffs we're making when we write Bash scripts, and not pretending like we have "zero dependencies".
> Try comparing the behavior of cp on macOS vs. a modern Linux distribution
Not many people are running macOS servers... and servers tend to be where most shell scripts are being used.
macOS has notoriously out of date versions of all system programs, CoreUtils and Bash among them, due to licensing issues with Apple's closed-source proprietary OS. BSD and Linux based systems, generally don't have this issue.
That being said, a regular Shell Script (not a Bash Script) will run unmodified on macOS. When people say "shell script", they usually mean an actual `sh` script instead of a Bash script.
At my current gig, our infra team - who all use linux - regularly break the developer workflow for the rest of the org, which is around 80% macOS - by using unsupported bash or coreutils features. When I look at the scripts I want to pull my hair out, their use of bash goes far beyond glue code and rivals the complexity of some of our smaller micro services.
Into the weeds - but sounds like your developers need a better development environment, one that more closely matches the production environment.
Thinking of macOS as "just another *NIX" really doesn't fly these days. Crazily outdated standard systems utilities is just the tip of the ice berg, really.
On the contrary - we use kubernetes heavily and our development environment matches production about as closely as possible for the architecture we have. But we’ve got to bootstrap minukube and seed configuration and data to uninteresting dependencies somehow. Using different scripts for that in development and production would be moving in the wrong direction, but I do often wish they were written in Python.
Has your team considered using a standardized VM to develop in?
Your team could then freely use whatever computer/OS they wanted, but also keep everyone's development systems consistent with each other, as well as avoid any strange Apple-induced issues that come with running Apple hardware as a developer in 2020.
You're really fighting an uphill battle with macOS these days... as sad as that might be for some.
You've spelled it out in a few different posts - macOS breaks everything for your team. So why fight it? Get a different OS to develop in... or dumb down everything because macOS uses crusty, old utilities.
> Has your team considered using a standardized VM to develop in?
How is that not what we're already doing? Minikube runs in a VM. But we have to set it up somehow. Running a minikube VM inside a maually configured linux VM makes no sense - if we did that, now we'd need a scipt to boottrap the linux VM.
> You're really fighting an uphill battle with macOS these days... as sad as that might be for some.
I can definitely see this becoming more and more true in many fields, but this hans't been an issue for us.
> How is that not what we're already doing? Minikube runs in a VM. But we have to set it up somehow.
I was implying a development environment inside a VM, not just a VM for testing.
You posted several times about how macOS isn't compatible with your production environments scripts and what-not. The solution is to either not use macOS, or use a standardized VM every developer on the team uses to develop inside of, so that your scripts work "out of the box".
> I can definitely see this becoming more and more true in many fields, but this hans't been an issue for us.
Your posts seem to contradict this. Perhaps you were exaggerating the pain it causes the team when production scripts don't work on developer systems. Either way - it seems the writing is already on the wall. Apple isn't going to make it easier any time soon - so ditch the mac's.
> You posted several times about how macOS isn't compatible with your production environments scripts and what-not. The solution is to either not use macOS, or use a standardized VM every developer on the team uses to develop inside of, so that your scripts work "out of the box".
Another solution would be to write those scripts against a language and standard library that doesn't have wildly varying behaviour between its underlying platforms. One of my side projects has a bunch of supporting scripts in Python doing similar things and they run exactly the same on Linux and macOS. They even run fine on Windows with only minimal modifications.
> Your posts seem to contradict this. Perhaps you were exaggerating the pain it causes the team when production scripts don't work on developer systems. Either way - it seems the writing is already on the wall. Apple isn't going to make it easier any time soon - so ditch the mac's.
With this statement I was referencing specifically the complaints that have surfaced in the past few years about new OS changes and security features breaking tooling. I don't count our infra team using new bash features in this because the issue with outdated bash/unix tooling is a long-standing one.
I can't speak for others, but for me personally, the usability of macOS for almost all of the things I do on a day-to-day basis is just day-and-night better than anything else, even if I have to hack up a bash script to work correctly from time to time. I will say the difference is less than it used to be - I use it occasionally and Linux has come a long way in the past 10 years.
This is basically what writing a Python script is. Python code is compiled into Python bytecode and interpreted by the Python VM, after all.
(I know what you mean by VM, but I don't think the distinction is very important here, you get the same benefits either way, and using Python is arguably a lot simpler than using a full VM.)
What you describe is 100% real and is why `brew install coreutils findutils gnu-sed` has always been a prerequisite for any developer whose dev environment I've been tasked with supporting.
That’s definitely one solution and I have resorted to it from time to time, but it’s far from perfect - now anything that detects macOS and uses different options is broken.
So what you can do, though, is not link them in and your scripts can use their Homebrew directory to get ahold of the GNU binaries. It is still a script change you have to make, but it's one you can make at a top level and then your bash wranglers are very unlikely to break them.
(Though I use those as daily-driver packages on Macs and have actually never had something break? GNU tools tend to support BSD options.)
Maybe this is easier with the way homebrew does things (I prefer MacPorts) but then you have to manage a bunch of symlinks to bring in the stuff you DO want to use by default.
I actually hadn't thought to try this approach, though. The next time this happens I will definitely give it a shot.
I'm not saying Python isn't without its problems too. I don't even like using Python that much for scripting. But we should be clear about what tradeoffs we're making when we write Bash scripts, and not pretending like we have "zero dependencies".