What are non-POSIX shells and what's the point of them?
I've been learning some Linux and I finally feel like I can find my way around the command line. But now I hear people say there are other, "non-POSIX" kinds of shell, with different semantics. What are these for?
1 answer
From the average user's perspective:
Back in the day when people were figuring out how to do shells, there were as many shell syntaxes as shells. Everyone made up their own little language to go with their shell. Most of them sucked big time. One sucked a bit less, that became bash. The others died, bash stuck, and became "the" shell.
Bunch of other dudes got together and thought that instead of writing a shell, they'll just write how the shell should be. Sounds easier! That went into the POSIX standard. I don't think anybody really follows the shell syntax in it, maybe sh
does. It's basically bash, except there's a few differences. Mostly, POSIX is slightly more annoying, but it also doesn't have a few of bash's rough edges. POSIX is not just shell syntax, it's a lot of other internal stuff, but in the context of shells people are usually thinking the syntax.
Now bash kind of sucks, it has a lot of dumb and annoying quirks. POSIX is not that different, so it doesn't really save you from it. So now there's a second wave of people making new shells, and trying to do better than bash. But if they really want to do better they have to give up on POSIX, but then people's old bash scripts won't run on the new shell, boohoo. So we have "non-POSIX shells" which try to rip the band-aid off.
Even with bash, you have zsh, which is supposed to be bash-compatible, but better. The better stuff in zsh is better, but it can't kill any of the bash crap, because it wants to stay compatible, so you can only go so far with zsh.
If you're really over bash:
-
fish
tries to do a saner language.and
not&&
, noif
/fi
orcase
/esac
buffoonery, sensible design top-down etc. It's mostly little changes, lose a dollar sign here, an equals there, but in the end, if you plug bash code into fish you get a million syntax errors and vice versa. Notably there is a tool that can translate bash into fish. Fish has some other weirdness like using a webserver to configure it and so on. But the syntax and overall feel is generally "bash but if it was clean". -
xonsh
- do you really love Python? Do you wish you had it in your shell? No, not likepython -c
, like for real your whole shell is Python? You got it! -
elvish
- bash programs do all input/output (STDIN and STDOUT) as text, so every program in a chain has to re-parse it. Elvish has types, also nicer syntax for scripts. Projects with similar goals:nushell
,marcel
-
oil
- another redesign of bash syntax/modern shell scripting language. Oil has optional bash compatibility. Note, the shell is now calledysh
- turns out, "oil shell" doesn't have great SEO... Notable in that the main dev has written an astounding amount of research and analysis on shell design.
Generally, non-POSIX shells are much nicer to use than bash and it's POSIX-y cousins (yeah bash isn't really POSIX either). Since bash was developed in the 80s, there's been a lot of neat ideas in programming and scripting. With modern non-POSIX you get to enjoy a lot of these. The drawbacks are:
- They all have different syntax, you don't know which one will win in 10 years and force everyone to learn it, and it will probably not be the one you pick today
- None of the scripts you find online will be for your shell - except fish, that seems to be getting some traction now, for example keychain supports fish now
- Nobody online will understand your scripts when you post them
- Once you get used to it, POSIX will be suffering and you will have to install the shell on every computer you use, it will never come pre-installed like POSIX
- A lot of them are new/experimental and do breaking changes often
I'm thinking here of modern non-POSIX shells. There's also old stuff like ksh
, csh
, don't use that, it's awful. They made bash to improve on those, that's how bad they are.
The oil/ysh guy maintains quite a list of alt-shells: https://github.com/oilshell/oil/wiki/Alternative-Shells
0 comment threads