I've used both and maybe it's because I'm just not doing anything beyond normal, basic stuff - but I don't see a big difference.
It's just Apple using zsh as a default shell. People tend to use defaults and a lot more people are exposed to zsh now.
Some developers have found out zsh before apple and customized it extensively. macOS switch just added fuel to the fire.
Then you start to feel insecure thinking it might be too weird and don't try it
Me (using fish): Hmmmmmm....
Hence, I'm on fish.
Combined with starship.rs, it's super easy to get a very nice shell with no config required.
That's a very recent change (1-2 years). ZSH has been extremely popular (and OMZ! etc), for a decade.
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).
But there's nothing extremely important about it being GPL3 and not GPL2 (except that it should follow the FSF dictums to the maximum).
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.
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.
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'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!
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.
I do realize `bash` also has `splat splat`, now.
(curse HN's splat/star pseudo-markup)
*a*b*c*d*
Looks like a code block is the only option. **
You can enable it on recent versions of bash with: shopt -s globstar 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=( DSC_<0450-0630>.JPG )
some-command -A${^x}
Runs: some-command -ADSC_0450.JPG -ADSC_0451.JPG -ADSC_0452.JPG …
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.
[1] http://zsh.sourceforge.net/Doc/Release/Expansion.html#Parame...
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'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 prefer using bash in this case because it means my bash scripts are more portable across different systems.
But when I write a script that's meant to be executed rather than sourced, I aim to use posix wherever possible, and fall back to bash if it's not.
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.
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.
So it really depends on your use case
In fact my shell dotfiles are mostly compatible with both, and when they’re not I managed to backport the interesting bits to bash.
TBH I use zsh only because it’s the default in macOS, where bash is both ancient and deprecated.
But zsh is not “simple enough”. The gajillion features are just dead weight and needless complexity to me.
And there's no particular glory in sticking with some older shell, else we'd still be using csh or sh.
bash wasn't actually present in mac OS X 10.0 AFAIK, it was added later. So zsh has just outlasted it.
In any case, csh and tcsh have some painful corner-case behaviors [0]
Switched to tcsh for the readline editing and history search.
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.
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'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.
[1] https://github.com/zsh-users/zsh-syntax-highlighting [2] https://github.com/zsh-users/zsh-autosuggestions
[1] https://github.com/landley/toybox/blob/master/toys/pending/s...
This may break something because it mapped a regular letter, so maybe `Control-g: '| grep'` is better.
Zsh: Initial release 1990, 30 years ago