I've been using Xonsh as my main shell for a few years now, and I'm really pleased with the switch.<p>There are some downsides you need to overcome:<p>* Slower to start. Takes a second or two before I can start typing when I open a new tab.<p>* Less stable. Upgrading will occasionally break something, or spit out warnings you gotta find a way to silence.<p>* Lack of compatibility. Tools that change you shell profiles to shim some executables (like rvm or pyenv) will not work. I typically source some files manually, or resort to bash if I need to.<p>* Tab completion is not straightforward.<p>But IMO I get ample compensation:<p>* I can write much better and cleaner scripts using Python's syntax and standard lib. Being able to use `argparse` is a blessing, compared to how you read arguments and flags in bash.<p>* I'm actually able to remember the syntax for looping and conditional.<p>* I'm more self-sufficient in the terminal for small things like arithmetic operations, generating a UUID, testing regexes, etc.<p>* Having typed/structured data in the shell, vs everything being plain text is also quite useful when you don't want to turn some easy task into some complex text processing pipeline.
I started with tcsh because it was the standard on BSD at the time, then I moved to zsh and never looked back. Using shells with non-POSIX syntax is nice in theory but the pros don't outweight the massive con of not working out of the box on most systems, at least for my usage.<p>The idea of using structured data instead of raw bytes always seemed like a brilliant idea, so I commend Microsoft for pushing the concept with their PowerShell, but I'm a un*x user and all the operating system and tooling is built around dumb `char[]` pipes so unfortunately that's a lost cause as far as I'm concerned.<p>I suppose a big player like Red Hat or Ubuntu could push for a complete migration of the kernel + userland towards structured pipes, but I'm not sure why they would. From anecdotal evidence it seems to me that shell power-usage is not as popular now than it was in the past, most junior devs I encounter seem to barely use pipes at all, let alone write complex scripts. They rely on VSCode to launch the build commands and they do everything else through GUI. When they need to do something on the CLI they usually just copy/paste from stackoverflow. Why bother overhauling the shell if it's becoming a legacy tool?<p>It saddens me a bit but I also get it. It's not like shell scripts and Makefiles and autotools stuff are a pleasure to work with... Maybe it's for the best.
One shell in that list that doesn't get the attention it deserves is execline - so much so that it isn't even in the Archlinux repo. Execline, unlike (probably all) other shells, doesn't stay memory resident until the script finishes. It (execlineb) interprets the script and then execs into the first command. Exec means that execlineb is finished at that point. The rest of script proceeds by exec chaining and occasional forking. All the commands run with the same PID, except when forking. This sort of chaining is apparently called Bernstein chaining.<p>Execline has a very low memory footprint due to chaining - something that's probably important for embedded devices. And it theoretically has less vulnerabilities associated with shells. It is the primary scripting language of the S6 process supervision suite.
A very long time ago, I've tried using IPython as my login shell.<p>Things that didn't go well:<p>- Startup time is not great.<p>- Many, many things will assume that your login shell is either a superset of /bin/sh; or at least when given "foo", will search $PATH for /usr/bin/foo, etc.<p>- I ended up using Python features much less often than the regular shell commands.<p>That said, I would welcome a new "alternative" shell that can balance the expressiveness of Python with ordinary simplicity of plain old Bourne sh.
It would be wonderful if someone would write a shell that implemented an LR-parsed language that could be expressed by a yacc grammar, that had equal functionality to dash, and kept the tiny size of dash.<p>The dash shell is small and fast, and goes places that other shells simply cannot follow.