4 ms·

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 with

by cle 6y ago

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".

Alupis 6y ago
> 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.
- xmodem 6y ago
  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.
  - Alupis 6y ago
    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.
    - xmodem 6y ago
      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.
      - Alupis 6y ago
        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.
        xmodem 6y ago
        > 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.
        Alupis 6y ago
        > 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.
  - eropple 6y ago
    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.
    - xmodem 6y ago
      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.
      - eropple 6y ago
        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.)
        xmodem 6y ago
        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.
        eropple 6y ago
        Homebrew does collate them all in a couple of directories for you, yeah.
- fomine3 6y ago
  *BSD also don't use GNU coreutils by default.
ascendx 6y ago
Python's shutil.copy() is worse in every respect, just look at the warnings in the docs. Shell is just better (cp -Rp for example is portable).

by cle 6y ago

Alupis 6y ago

> 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.

xmodem 6y ago
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.
- Alupis 6y ago
  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.
  - xmodem 6y ago
    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.
    - Alupis 6y ago
      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.
      - xmodem 6y ago
        > 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.
        Alupis 6y ago
        > 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.
- eropple 6y ago
  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.
  - xmodem 6y ago
    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.
    - eropple 6y ago
      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.)
      - xmodem 6y ago
        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.
        eropple 6y ago
        Homebrew does collate them all in a couple of directories for you, yeah.
fomine3 6y ago
*BSD also don't use GNU coreutils by default.

ascendx 6y ago

Python's shutil.copy() is worse in every respect, just look at the warnings in the docs. Shell is just better (cp -Rp for example is portable).