4 ms·
[[ is bash only. If you know you’ll only use bash, use it. For details, the article is nice.
by neverrroot 3y ago
[[ is bash only. If you know you’ll only use bash, use it.
For details, the article is nice.
- nerdponx 3y agoThat is, test and [ are specified by POSIX and usually are physical binaries (but might also be masked by shell builtins). Whereas [[ is not specified by POSIX and usually only exists as a shell builtin.
- shmerl 3y agoWhy 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 minimal common shell denominator.
- driggs 3y agoBecause Apple switched the default macOS shell from the GNU-licensed `bash` to the BSD-licensed `zsh`?
- bgm1975 3y agoApple switched when bash switched from GPL2 to GPL3 which they didn’t like. The older bash is still available.
- toast0 3y agoAccording 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 agobash 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 agoHonestly 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 agoNot 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 agoHonestly, installing bash into environments seems like less work than avoiding it. It's not hard to do.
- JohnFen 3y agoWhen 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 agoTime to find better customers.
- loa_in_ 3y agoWhat prevents you from shipping bash with your solution?
- JohnFen 3y agoThese 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 agoBash 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 agoThis 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 agoPowerShell's problem is that it is a real programming language, which makes it less suitable for a shell.
- hnbad 3y agoI was half-joking but the downvotes were to be expected in a conversation about Linux shells.
- usrbinbash 3y agoNo, 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 agoIIRC Debian uses dash as /bin/sh because it's faster (execution speed) than bash.
- emmelaich 3y agoThat'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 agoEh, 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 agoIIRC, /bin/sh on Ubuntu defaults to dash
- eikenberry 3y agoThat is from Debian and all child distros inherit it by default, not just Ubuntu.
- jabl 3y agoIf 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 agoIn fact, only dash is supported as /bin/sh on Debian and Ubuntu.
- JohnFen 3y agoI'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 agoStill sounds archaic that it's a problem today that needs to even be addressed.
- jtafurth 3y agoI 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 agoit’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 agoWriting 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 agoIt'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 agoThat doesn't make it less archaic if anything today still has this problem.
- usrbinbash 3y agoWell, 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.
- re 3y agoWell, zsh too :) https://zsh.sourceforge.io/Doc/Release/Conditional-Expressions.html https://zsh.sourceforge.io/Doc/Release/Conditional-Expressio...
- bgm1975 3y agoAnd ksh (ksh88 & later)
- dredmorbius 3y ago"bash only" typically refers to "bashisms", that is, bash features not present in the plain Bourne shell (or Bourne-compatible interpreters such as dash). The fact that other shells (such as zsh) may include those features ... is beside the point of writing universally compatible shell scripts. Confirming my facts for this comment, #TIL that "dash" is the "Debian Alquist Shell", that is, Debian's "ash" shell: <https://en.wikibooks.org/wiki/Guide_to_Unix/Explanations/Choice_of_Shell https://en.wikibooks.org/wiki/Guide_to_Unix/Explanations/Cho...>
- emmelaich 3y agoAlways use [[ zsh and ksh have it; in fact I'm pretty sure it originated with ksh in 1988 or earlier.
- OmarAssadi 3y ago> Always use [[ While zsh, bash, mksh, ksh93, probably others have it, sure. But many don't -- and not totally irrelevant ones either. Debian's default, dash, for example, does not support `[[`. IMO, unless you're writing something like shell-specific dotfiles, avoid non-POSIX features. It's usually pretty trivial to avoid them, especially if you're willing to call other mandated commands like awk, etc. But often, with a bit of creative thinking, most non-standard features can be replicated with some combination of `set`, separate functions and/or subshells. Shell scripts, in general, have dozens of footguns, are pretty much impossible to statically analyze, difficult to make truly robust, and many of the shells themselves -- e.g., bash -- have huge, borderline inauditable codebases. I can think of a dozen reasons not to write shell scripts. Yet still, there is incredible value in the fact that some form of POSIX-compliant/compliant-enough shell can usually be found on most systems. All of that value goes out the window, though, the moment you start relying on non-standard features.
- massysett 3y agoDon’t worship at the altar of portability. There is real cost to portability, as it forces you to cater to broken implementations and to not use features that may be very useful. Also, it can be difficult to ensure compatibility with systems that you don’t test on, so true portability requires having different systems to test on. Sometimes all those costs are necessary for the task at hand. For example, the whole point of GNU Autoconf is that it runs on a wide variety of systems. On the other hand, many programs are for in-house or personal use and will not run on obscure systems. The cost of writing for portability simply might not be worthwhile in these situations. And that’s ok, notwithstanding some conventional wisdom of “always try to be portable.”
- arp242 3y agoDepends what you're writing. If you're writing an installer script or whatever that's going to be run on $many computers that you don't control: sure, it's probably best to go to the extra effort to stick with POSIX sh. But that's not most scripts. Most scripts are things that you run on computers you control. I just write things as zsh scripts because it's so much easier than bash (never mind POSIX sh). That's fine, because I can just install zsh. And actually, this often makes scripts more portable because you need to rely on external utilities a lot less.