Bash 5.1
lists.gnu.org
lists.gnu.org
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.
That's a very recent change (1-2 years). ZSH has been extremely popular (and OMZ! etc), for a decade.
Then you start to feel insecure thinking it might be too weird and don't try it
Hence, I'm on fish.
Combined with starship.rs, it's super easy to get a very nice shell with no config required.
Me (using fish): Hmmmmmm....
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!
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.
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).
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)
for i in (#i)*.png~*orig*(oL); convert $i $i:r:l.jpg
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 …
ls -l **/src/**/*(.x)
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?).
**
shopt -s globstar *a*b*c*d*
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.
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]
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.
Switched to tcsh for the readline editing and history search.
And there's no particular glory in sticking with some older shell, else we'd still be using csh or sh.
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
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
https://github.com/dylanaraps/pure-sh-bible is a good example if you look at the issue tracker.
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.
"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.
Maybe that changes, but if you right for bash that's portable enough - you need to balance the work required with the risks of not doing it.
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.
In some contexts, Python is also a pretty good option as it is available in a lot of places as well.
args=("my" "arg" "with space")
bash -c "rm ${args[*]@Q}"
https://www.gnu.org/software/bash/manual/html_node/Shell-Par...
${parameter@operator}
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.
They also become nonstandard.
Obviously it all depends on the context.
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:
There are many better designed languages out there, but to this date, none is as omnipresent as the POSIX shell language.
$ /bin/bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
Copyright (C) 2007 Free Software Foundation, Inc.* People who use the shell often enough to be bitten by having an old version of bash know how to update it
* People who use the shell infrequently enough not to be bitten by having an old version of bash don't care
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.
What is wrong with Alpine and the BSDs? Do they also use old bash versions?
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.
Another day, another reminder to Be More Careful.
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
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.