5 ms·

Are there any systems that run Bash but do not include CoreUtils? I think not... A shell script is literally intended to "glue together" external programs, inc

by Alupis 6y ago

Are there any systems that run Bash but do not include CoreUtils? I think not... A shell script is literally intended to "glue together" external programs, including all of CoreUtils. If you are doing more than just "gluing together" other programs, then you are programming, not scripting, and you'd be far better off reaching for an actual programming language instead of a shell script of any kind. Python has plenty of warts too. You can't depend on it being installed on any given system, can't depend on the version even (Python 2.x or 3.x?), which libraries are installed, environment, venv support, etc.

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.
  - 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).
syntonym2 6y ago
Python is by default installed on RHEL, CentOS, Debian and many more, the noteble exception are BSDs [0]. Python 2.4 was released in 2004, by writing python 2.4 compatible code you should cover everything besides ancient mainframes. While python 2.4. does not contain all niceties of modern python, it has lists, sets, dicts and the subprocess module which makes writing bash script comparable scripts very doable. [0] https://unix.stackexchange.com/a/24808/317276
- ric2b 6y ago
  Why Python 2 instead of 3? There are several distributions that no longer ship it, and AFAIK it's no longer supported as of 2020.

by Alupis 6y ago

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

syntonym2 6y ago

Python is by default installed on RHEL, CentOS, Debian and many more, the noteble exception are BSDs [0]. Python 2.4 was released in 2004, by writing python 2.4 compatible code you should cover everything besides ancient mainframes. While python 2.4. does not contain all niceties of modern python, it has lists, sets, dicts and the subprocess module which makes writing bash script comparable scripts very doable. [0] https://unix.stackexchange.com/a/24808/317276

ric2b 6y ago
Why Python 2 instead of 3? There are several distributions that no longer ship it, and AFAIK it's no longer supported as of 2020.