I know that zsh is the hot new thing, but I've been using bash for about 30 years, and at this point, sheer inertia means it's unlikely I'll ever switch away. Long may it continue.
Indeed. I've switched to zsh a few years before it become a default on macs. If only I do not really remember what pushed me there, probably there was a wave of "zsh is awesome" sentiment over the internet.
You are correct about the recent change but I think that Apple making the default change exposes a program like ZSH to many tens or hundreds of thousands of people who have no idea what a shell is. I'm sure there are many people around the world who wanted to achieve something on their Mac, found online to open "Terminal" noticed the shell said "Bash" or found something online about Bash scripts, or commands, etc and this leads them down a hole of learning. This can add a lot more than people would think.
Yeah. I've gotten to the point where I hate tweaking things, and zsh feels like a pit of endless tweaks. I'm sure I could go dig up someone's package that has sane defaults, but, I ultimately don't care enough to do the work to vet _that_ configuration.
And I've already got a nice customized bashrc file. Maybe some of that comes out of the box with zsh (who admittedly I've only sort of tried), but not sure its worth the effort to change.
I remember it getting popular years before macOS switched. I believe Oh My Zsh (a zsh framework) being popular when I first tested it out and that looks to be 10 years old.
The things that got me to try it was being mostly compatible with Bash and having a lot of features that Bash only got later. I remember liking recursive globs, which look like they got added to Bash 4, but my OS may not have had it at the time.
Zsh has a lot of features, and some can be actually useful. In my case, I find, for example, customizing the right part of the prompt useful; additionally, there are improvements that one gets out of the box, like better copy-paste.
However, when I've asked to colleagues of mine why they used it and how, I've found that nobody knew anything beyond the basics.
I've tried to go beyond the basics myself, but I've found the manuals very obscure, and I gave up. Nowadays I use it for my shell, while I use bash for scripts.
Considering that there's nothing radically better, or at least, that there's nothing radically better _and_ easily accessible, I think that it will always be either a niche, or a tool used in a very basic form. I also think it will realistically never take off in scripting.
I'm much the same. Occasionally I discover a new feature and it has a positive effect on my workflow, but on the whole it's mostly me reaping benefits from the improved shell prompt.
I've been trying to stick to literal shell (as in /bin/sh) lately for portability reasons - but every once in a while there's something in bash that makes my life much easier!
Since OSX was forcing it down my throat, I switched to zsh. I suffered for a couple of months and am now happily back to bash. I’m sure all these behaviors could have been changed in zsh but I’m believer in defaults, so the different tab completion behavior and handling of asterisk drove me absolutely bananas.
Not quite sure what you mean by being a "believer in defaults"?
Bash an zsh both copied sh and ksh (88) fairly faithfully on old features. Where they diverged on newer things, bash nearly always acquired the feature later than zsh and only very rarely implemented things in a compatible way. Especially for interactive features, I don't think they've seen any need to be compatible. Zsh made more effort on easing things for old tcsh users. It is only on Linux where bash came to be a "default" – if you want pure defaults, see how you enjoy either early sh or a pure POSIX variant as an interactive shell.
Where differences drive you bananas, a little effort to find the right knob to tweak and to stick with it would be rewarded in the long run as you explore the nicer features at your leisure. I'm guessing the asterisks is `setopt NOMATCH` to tweak or, otherwise to understand the benefits of the zsh default.
>Since OSX was forcing it down my throat, I switched to zsh.
Forced it? I've used a custom bash (v. 4) on OS X and not Apple's older bash for a decade or so, and I'm using fish since the last 2 years, not the OS X zsh.
It's trivial to change shell (basically, chsh, as in any Unix).
The only reason Bash exists at all is because of the very same reason Bash switched to GPLv3. There could be no theoretical world where Bash exists but stays with GPLv2.
I’m sure GNU would love Linux. I’m also sure Linux would be GPLv3 if it was a GNU package for the last 20 or so years. But now people who wrote Linux are dead and they can’t relicense easily.
I thought oil shell was the hot new thing. I really think it has the potential to displace both bash and zsh.
My impression has always been that zsh is where cool new features go first, and then bash plays catch up. I remember longing for associative arrays in bash while zsh and ksh already had them. What finally got me to move to zsh was colorized syntax; it makes some of my typos very obvious before I press Enter. In general zsh is still more pleasant for interactive use, but I still write scripts in bash since it is everywhere.
zsh's killer feature for me was "splat splat" and the extended shell globbing; `<splat><splat>/foo<splat>(.x)` type stuff. Replaced `find` for a lot of my interactive stuff, although I do use `find ... -print0 | xargs -0r ...` for a lot of things yet.
I write scripts which don't need to be portable using Zsh, and I find it very useful for interactive use too. If I'm handling a lot of files/file formats, the parameter expansion flags are very useful:
for i in (#i)*.png~*orig*(oL); convert $i $i:r:l.jpg
That's a (#i) case-insensitive match for ∗.png, but excluding ~ files matching ∗orig∗, and (oL) ordered by length/size.
The $i:r strips the final file extension (i.e. .png), and the :l downcases the filename.
x is set to an array matching files like DSC_0500.JPG, where the number is in the range 0450-0630. The -A${^x} expands the array, prefixing each entry with -A.
ls -l **/src/**/*(.x)
Recursively list all plain files (.) that are executable (x), and where the directory "src" is somewhere in the path.
Have a look at "man zshexpn" (then "Parameter Expansion") or [1], then "Filename Generation" further down. 30 minutes reading this is worthwhile for anyone who uses Zsh regularly.
> I do realize `bash` also has `splat splat`, now.
To put a date on that: Since Bash 4.0 in 2009.
Which is ~forever since you tried zsh in 1993, but is also ~forever ago now.
As for when zsh got it: It had "..../" in 2.0 (maybe before), that got changed to "<four splats>/" in 2.1.0 (1992?), and that got shortened to "<two splats>/" in 2.2.0 (1996?).
I never heard of oil shell, and to be fair the name really doesn't help with its discoverability since there's already a big oil company using that name.
I'd say oilshell is the next thing, and fish is the hot new thing.
I check in on oil from time to time, and I think it's headed in the right direction. Zsh is way too crazy for me - I'm quite happy with bash. But I sometimes spin up fish, and might be tempted over at some point.
I wonder if POSIX/sh is really necessary if you're targeting Linux. I mean, if you're targeting multiple Unixes, sure, but a lot of my scripts are company/infrastructure specific and won't really target anything but Linux and bash is always available. Even if we used a BSD for something tomorrow, it'd be trivial to add bash to those. I may be missing something, however.
I guess the one place I can think of is some small-container scenarios, e.g. a bash-less Alpine, where you want the smallest possible image.
No, I don't think POSIX is as necessary as many people make it out to be, because it really depends on your use case. I've always been able to rely on bash both professionally and in my own projects.
I am however aware of people who have to rely on posix compatibility. One of them is as you said, docker environments and alpine Linux, the other is a former colleague was working on some airgapped system where security didn't allow any additional packages to be installed, and bash wasn't installed. So their only way of scripting was either posix, or an old version of python 2 (I think it was 2.3). I don't know whose brilliant idea it was to install python, but not bash.
I tend to check every script I write using shellcheck[0]. This will detect if a script starts with `#!/usr/bin/env sh` but uses bash or zsh features. Never had a problem an never thought much about it.
I don't recall ever running into something that didn't work in plain sh. I have never scripted in zsh. I'm probably missing out on some advanced features, I guess.
I'm trying to remember why I was dealing with csh/tcsh so much on MIT's Athena in the late 1990s. Perhaps tcsh was the default shell there (or maybe just on the Solaris or IRIX workstations). Maybe some old-timer convinced me early on to change my default to tcsh.
In any case, csh and tcsh have some painful corner-case behaviors [0]
I would have claimed bash came only with Linux. That's not true. But it was not very known at the days. I guess only Linux changed that, using it as default shell in many distros.
tcsh had the reputation of being more usable than Bourne shell. (The quirks related to programming meant the cautious people used it only interactively.) So Bourne again did never sound like good marketing to me. It took me years to try it even after the years I had not even heard about it.
That's my memory of Athena from those days as well, though I cannot say why that was. Definitely agree with csh and tcsh being painful. But being the first shell I got to know, I still know it well and better than the alternatives...
I still use csh, the original one without line editing. I find faster most of the time to perform string substitution over the history. There is no glory, it’s the use of the same tool every day for 20 years.
I've been using fish for the past few months and the jury is still out. On one hand, the out of the box behavior and configurability is fantastic, and by default it is very pleasing to the eyes.
On the other hand, on my macOS there was a noticeable lag after I hit enter on a command that is not in bash. I also have very little attention span for figuring out fish's unique function loading system to pimp my shell like I would bash.
I think fish is great for newcomers or for those who don't really want to mess around with too many settings or plugins.
I'm a fish user, actually. That said, for those on zsh who want some of fish's most prominent user features without leaving, check out zsh-syntax-highlighting[1] and zsh-autosuggestions[2]. These are rather popular so long time users may not benefit from these suggestions.
Interesting. I also used fish for a while after looking at bash alternatives, but ended up with zsh, because fish had some (admittedly minor) inconveniences/bugs, and zsh felt more mature. But very soon I had to install the two extensions you mentioned because my shell felt really incomplete without them after fish.
My journey is the opposite to you, I started with zsh and those two plugins. It's good to have bash like syntax (easy for copy paste from the web), but the slooooooooow startup speed really annoys me, so I give fish a try and now I'm impressed by its speed and feature.
I would find such a lag very irritating, but it's fine on Linux. Using Bash for years and I realized that I could never remember all its corner cases - fish is much easier to fit in the head. And _personally_ I don't need to be POSIX. (The function loading system is pretty simple and makes so much damn sense after years of .profile etc)
It is. Around these parts, people use “hot new thing” as code for “thing I don’t like” regardless of the thing’s age or actual popularity. It’s not meant to be an actual statement of fact.
Rob Landley is working on implementing a full Bash clone (called toysh[1]) in his Toybox project[2], so hopefully the need to target BusyBox ash will go away in the near future.
This always trips me up when I run `docker exec` to get a shell in a container that is based on Alpine. "/bin/bash" is too far ingrained in muscle memory.
I find zsh mostly compatible (at the level I use shells). When developing scripts, I use the bash shebang, but I'm trying individual parts in my interactive shell. It's quite rare that I need to start bash. Often, zsh works the same.
I used to think that way, but POSIX is not that well specified and there are tons of little behavior changes that makes the task difficult past 10 lines of code. Writing portable shell scripts is like writing portable JavaScript in the IE days.
Once you accept Bash as a standard things become much easier. Basically Bash arrays, the `@Q` notation and ShellCheck combined solve all of the escaping issues that plague shell scripts.
I can't think of a system that would be using anything I write that wouldn't have bash, honestly. Not in... 25 years or so.
"portability" I guess is a goal, to a degree, for me too since I write in bash instead of zsh which I use interactively, but /bin/sh scripts for "portability" is just a fetish, IMO.
Bash and shellcheck mitigate the issues but Powershell (and some newer shells like Elvish and Oil) actually solve the issues by introducing proper objects and breaking the defaults bash expects.
Bash suffers from a similar problem to Perl and other 20+ year old "get it done" languages that they need a strict-mode bolted on, and a bolted-on strict mode is strictly inferior to just having the language behave sensibly to begin with.
What cb321 said. Sometimes programs take a single argument that contains the whole command. @Q allows to safely escape the list of arguments. This is a synthetic example:
I belive zimbatm refers to the bash-specific ${var@Q} to expand to a form suitable as re-input into the shell. There are a few other bash-specific syntaxes like that (under "parameter transformation" in the manual page).
The expansion is either a transformation of the value of parameter or information about parameter itself, depending on the value of operator. Each operator is a single letter:
Q The expansion is a string that is the value of parameter quoted in a format that can be reused as input.
Unless you have an encyclopedic memory and copious leisure time, you'd probably be much better off writing perl scripts instead if you care about portability. There is an enormous amount of sometimes subtle divergence between behaviors of core tools you need for shell scripting (sed, tr, mktemp, readlink all behave very differently between different versions of unix,for example) and even if you manage to memorize exactly what's in posix (and accept the fairly severe limitiations in expressiveness this entails), few things are actually 100% posix conforming.
I use the POSIX documentation as my primary source of documentation when writing scripts. Most of the time, I have seen that the differences between the implementations are in the additions but not in the core functionalities that are described by POSIX.
A nice entry to the POSIX documentation is being provided by this website:
While I appreciate the existence of POSIX as a standard, I wonder how we could come to a place where it would be actually good. Don't get me wrong, there are many positive things about POSIX shells, but in my opinion, the language itself is broken (how many errors are caused by whitespace in the wrong place?) and error handling in particular is just horrible and unreliable.
There are many better designed languages out there, but to this date, none is as omnipresent as the POSIX shell language.
Well, not entirely. The problem I have is that this old version has serious bugs.
So you write a bash script, test it with a modern bash and everything looks fine. But then you start the same script on a fresh macOS and it doesn't run. Took me a while to figure out it wasn't because of my script but because of the outdated bash version on macOS.
And I am not talking about 'don't use that option' kind of bugs but more along the lines of 'when you nest too many sub-shells it doesn't find its way back and throws a syntax error'. So if you want to make sure your scripts work out of the box on macOS you have to test against that old buggy shell.
No, they just don't have Bash out of the box. Bash isn't universal. Nothing really is, but Bash definitely isn't. Expecting Bash to work on MacOS without checking seems weird to me, since most it doesn't work on most OSes by default.
Not having bash installed by default is not the issue here. The issue is that macOS comes with a buggy version of bash and those bugs cause valid scripts to fail in a unique way. So at first you might think everything is just fine (because there is a bash) and but in fact you either have to test against those bugs or install a newer version.
A while back I used MacPorts to install the latest bash and changed my admin user to use it. Worked great. Then Big Sur came along and I had to upgrade MacPorts. This involved uninstalling installed packages, upgrading the base MacPorts, then reinstalling the packages.
Imagine my surprise -- because I didn't fully consider these actions -- when my terminal session started ignoring my commands partway through that process. It turns out that it is a Bad Idea to delete your shell binary when you're using it.
Fortunately, VS Code's terminal uses a different shell binary so I was able to complete the upgrade there.
To be more specific, zsh was already included before, but the default shell for new accounts is now zsh instead of bash. Apple still ships /bin/bash version 3.2 with macOS.
Not in the same way Apple has. Apple does not ship with any GPLv3 code meaning no new version of Bash. While Linux never migrated to GPLv3 from v2 many distros ship with v3 code.
Let's take a moment to remember, that while bash is good, there are other shells out there as well. UNIX is great in that it offers a choice, and we should not lock ourselves into a shell monoculture (similarly to how a web browser monoculture is bad for everyone in the end).
Some of us believe rather strongly that tcsh is way better, some of us prefer zsh, and that's fine!
It's a good idea to take a look at other shells, at least to know what's out there and to make an educated choice, rather than use "what most people use".
So, next time you write a script or instructions, please remember that not everyone uses 'export', and also that not every /bin/sh is a bash.
I personally prefer using what most people use. It may not be perfect, and I may be miss a few nice features, but I find myself more productive this way
> Some of us believe rather strongly that tcsh is way better, some of us prefer zsh
Those people are wrong, though ;p
In all seriousness, one should look around and try a few. As a linux/Unix shell i like bash - it's posix enough that you can write posix-ish scripts (might have to run on ksh/bsds) - and these days it has good completion and other niceties. And unless you make an effort, it doesn't colorize everything to the point that it looks like your user land threw up on your terminal.
Other worth looking at IMNHO ibnclude rc from plan9, fish and oilsh. And maybe dash for a small runtime for scripts.
