5 ms·

Why would you not use Bash (unless you are using completely different shell like Fish explicitly?). It feels like some completely archaic concern to target the

• driggs 3y ago
  Because Apple switched the default macOS shell from the GNU-licensed `bash` to the BSD-licensed `zsh`?
  • bgm1975 3y ago
    Apple switched when bash switched from GPL2 to GPL3 which they didn’t like. The older bash is still available.
    • toast0 3y ago
      According to the interwebs, zsh became default with Catalina in 2019 [1]; ten years after bash 4 was released with gpl v3 or later. Also, the interwebs suggest Apple used to use tcsh as the default shell[2]; I don't know when they changed that, but it may have been after bash 4 released? (Thanks, 10.3 was in 2003, so several years before the license changed) [1] https://www.theverge.com/2019/6/4/18651872/apple-macos-catalina-zsh-bash-shell-replacement-features https://www.theverge.com/2019/6/4/18651872/apple-macos-catal... [2] https://news.ycombinator.com/item?id=18853318 https://news.ycombinator.com/item?id=18853318
      • masklinn 3y ago
        bash became the default shell in 10.3. tcsh was the default before then.
    • masklinn 3y ago
      > Apple switched when bash switched from GPL2 to GPL3 Apple just didn’t update. It took them years to finally switch to switch to zsh. > The older bash is still available. Aside from it being bash (a great reason not to use it as far as I’m concerned) it’s now a 17 years old version of bash.
      • toast0 3y ago
        > Aside from it being bash (a great reason not to use it as far as I’m concerned) it’s now a 17 years old version of bash. I thought people liked macOs for its vintage feel? Remember a time when computers could only render a single menu bar in a fixed location, feel the experience of SYN floods, run a version of bash that is old enough to vote in the next presidential election.
        • mkesper 3y ago
          Honestly this is such a waste of time every time I have to argue with developers about installing up to date homebrew (or whatever) versions of the coreutils that I wish Apple would simply DELETE all these ancient versions of tools from MacOS. As a bonus, homebrew does not offer --with-default-names any more and some tools (like make) are posted into different paths so you need to add your own symlinks or add multiple paths to your PATH.
• LambdaComplex 3y ago
  Not installed by default on BSDs. Sometimes not installed in minimal environments, e.g. where BusyBox is all you have available. Maybe not installed by default on Unixes? Not sure
  • loa_in_ 3y ago
    Honestly, installing bash into environments seems like less work than avoiding it. It's not hard to do.
    • JohnFen 3y ago
      When your script will be running on customer machines, you often don't have the luxury (and sometimes it's not technically possible because it doesn't exist) of installing bash into the environment.
      • DonHopkins 3y ago
        Time to find better customers.
      • loa_in_ 3y ago
        What prevents you from shipping bash with your solution?
        • JohnFen 3y ago
          These scripts are often used to install the application, so that introduces a chicken-and-egg situation. How can I install bash before running the installer? Also, we'd have to build and maintain our own just for platforms missing it, which increases cost and complexity. It's easier, cheaper, and less error-prone just to use a minimum common denominator that runs on everything. Additionally, when your customers have strict policies regarding how applications are approved for use and have to vet and test everything you give them, it's best practice to avoid installing anything that you can avoid installing. Doing that minimizes the effort and hassle for both the customer and the developer.
• mikem170 3y ago
  Bash seems to be about as archaic as sh. I write my shell scripts in sh, because it comes with every unix-like os by default. I know that bash has more features, but I've never really missed them. I switch from sh to perl for more complicated tasks. To each their own, right?
  • 15457345234 3y ago
    This to me seems like good practice, it's better to use a 'real' programming language when you're crossing the boundary from 'script' to 'program' Shellscript has way too many idiosyncracies and weirdnesses that would have been beaten out of a proper programming language by now. (I know that talking about weirdnesses is amusing in relation to perl which also has a whole armload of them.)
    • hnbad 3y ago
      > This to me seems like good practice, it's better to use a 'real' programming language when you're crossing the boundary from 'script' to 'program' PowerShell would like a word with you.
      • account42 3y ago
        PowerShell's problem is that it is a real programming language, which makes it less suitable for a shell.
        • hnbad 3y ago
          I was half-joking but the downvotes were to be expected in a conversation about Linux shells.
        • usrbinbash 3y ago
          No, power shells problem is that it cannot decide whether it's a programming language or a shell REPL, and ends up doing both badly. The syntax is too cryptic (and far too verbose) for a REPL, and too "shell-y" for a PL. bash, for all its many many many flaws, is quite clearly a REPL first, PL second.
• yjftsjthsd-h 3y ago
  IIRC Debian uses dash as /bin/sh because it's faster (execution speed) than bash.
  • emmelaich 3y ago
    That's like using a horse instead of a mule. Just not worth it. Move away from the whole equine world and use a real programming language.
    • yjftsjthsd-h 3y ago
      Eh, there are things that shell is really good at, and there are things that other languages are good at. I will grant that shell is best for glue code; my personal heuristic is that I stick to POSIX sh, and if that hurts then I take that as a sign that I should be considering moving to Python or whatever. But avoiding it completely strikes me as a poor choice, because for the "glue together separate programs and manipulate files" tasks that it's meant for, it's really good and IMO everything else still falls short.
• aidenn0 3y ago
  IIRC, /bin/sh on Ubuntu defaults to dash
  • eikenberry 3y ago
    That is from Debian and all child distros inherit it by default, not just Ubuntu.
    • jabl 3y ago
      If you want to nitpick, it was first done by Ubuntu and then later upstreamed into Debian (from which other child distros, as you correctly point out, inherit it).
  • andrewshadura 3y ago
    In fact, only dash is supported as /bin/sh on Debian and Ubuntu.
• JohnFen 3y ago
  I've worked on several modern projects that needed to be able to run on a wide variety of Unix platforms, several of which didn't have bash. Writing for the common shell denominator was important, not archaic.
  • shmerl 3y ago
    Still sounds archaic that it's a problem today that needs to even be addressed.
    • jtafurth 3y ago
      I wouldn't say it's an archaic problem, an example I can think of is writing scripts for infrastructure running minimal docker images where you want to keep the image size to a minimum, you would usually need to support both bash and other shells. Embedded applications come to mind as well.
• csydas 3y ago
  it’s contextual as most things. need to actually use and work on the machine? use whatever shell you want to make your life easier. need a script to run on many different systems and/or need to write a script to be managed automatically by a service account? probably you want a shell with syntax that is guaranteed to be the same on all your systems.
• dredmorbius 3y ago
  Writing Bourne-compliant scripts ensures maximum portability. As many here have noted, bash isn't universally available, with another possible issue being OpenWRT devices. Stock/base images tend to use a Bourne-compatible shell, not full Bash. Though the latter's installable through opkg, for sufficiently small devices (typical of consumer kit), you simply won't have the space to install them. There's also the slight PITA that Apple's OSX ships with a very old, pre-GPLv2 Bash, out of licensing concerns. (Apple is phenomenally averse to GPL-based code, much as some *BSDs are, such as OpenBSD.) And if you're dealing with legacy systems (which tend to be extraordinarily and stubbornly persistently legacy), you'll often find that either bash isn't present or is quite dated. I freely confess that I tend to write fairly recent-feature bash scripts myself by default, and appreciate many of the newer features. But if and when I am writing portable code, I'll go back to Bourne-compatibility. But when writing system level code, an appreciation for standards and the very long tail of legacy standards and the limitations they impose is in fact a large component of professional maturity.
• bregma 3y ago
  It's archaic if you're a dabbler, a hobbyist, an academic, or a junior dev who lacks the experience of shipping software into the wild. For the rest of us, we have learned the hard way, sometime repeatedly, portability and adherence to published standards matters.
  • shmerl 3y ago
    That doesn't make it less archaic if anything today still has this problem.
  • usrbinbash 3y ago
    Well, I am a professional who administrates quite a lot of systems. And they all run bash. They all understand `[[`, they all understand `~=` If any of them did not, then I'd ensure they do. Yes, shells that do not support modern bash syntax ARE archaic, no matter who sits in front of the screen. And same as I consider it part of my job description to keep systems up to date with security patches, I consider it part of my job to ensure they use modern versions of contemporary and widely used scripting languages and shells. And that includes bash. So no, relying on features that can be expected on a modern system is not a sign of inexperience. Same as a dev is within his rights to not write his python code under the assumption that it has to talk with a python 3.4 interpreter, he is within his rights to not expect a system that only knows sh.