A late update:

jkl Wrote:ksh93 everywhere because of POSIX.

I have actively decided to use different shells for scripting and interactive use for quite a while now and I have come to the conclusion that standard compliance does not matter for the latter at all. My shell scripts usually point to the bosh wherever I can compile it so I can be sure that they are relatively portable to anything that implements POSIX, just in case.

Interactive shells are a different thing though. The maximum "scripting" I do without writing a complete script file is looping over a set of files, so the scripting language is neglegible. The more important feature is the ability to find stuff in my history. One of the longest non-scriptable command lists which I regularly need consists of six commands and has different parameters towards the end, so finding it easily after a week of doing other shell work would be a good thing.

As I found myself using a different shell on almost all of my (non-Windows) machines, I am currently re-evaluating my options. macOS uses the zsh by default now, and as I spend more and more time on macOS, I gave it another try only to find that it is quite annoying to use as it tries to be smart and it really should not. I tried the ksh2020 today, but it is really the opposite of stable just yet. Too bad!

My preferred shell should

• draw in as little additional dependencies as possible,
  
• be a suitable interactive shell, i.e. not optimized for pure non-interactive use (sorry, bosh and rc!),
  
• have acceptable globbing, tab-completion and history functionalities,
  
• have a relatively fast startup time and a low resource usage (sorry, zsh and PowerShell!),
  
• be in a mature state, not a "technical preview" anymore (sorry, nushell!),
  
• come without any VCS integration out of the box or make it easy to get rid of that (showing your repository state is not a shell prompt's job in my opinion),
  
• generally be configurable in a way that does not piss me off while using it,
  
• be portable so I won't have to think about which shell I use every time I ssh into a different non-Windows system.
  

After checking the usual repositories and playing with some of them for a while, I narrowed down my selection a bit. I even included shells which I actively disliked for non-technical reasons before.


I did all of my tests in a Debian Unstable bash on Windows 10, the performance tests were done without changing any of the distribution's defaults; I temporarily renamed the .bashrc file though, so I could start from scratch.


1. Performance and resource usage


Results:


Interesting: The tcsh is roughly twice as slow as the penultimate runner, and the ksh93 even outperforms the "native" bash. What about the resource usage? I opened all shells with a $sh -c sleep 1d & and checked the vsz= output:


As you might imagine, this was my moment of getting rid of the fish shell again. I mean, wtf? The mksh's sleep weirdness will be ignored by me though. I hardly ever need an interactive "don't do anything for a while" command under most circumstances.

Let's give the other shells a spin.


2. Real-life test

For the real-life test, I did (of course) modify at least some of the defaults.

2.1. tcsh

I know, I know: The tcsh is bad for scripting and its syntax is a mess etc. etc. - hooray for the shebang, I guess. I configured some of it:


Globbing: cd */*oo* moves into "shelltest/Foo".
Tab-completion: cd sh<tab>f<tab> moves into "shelltest/Foo". Good.
History:
- Ctrl+R sh<Enter> performs cd shelltest/Foo.
- !! brings back the previous command.
- !-3 brings back whatever was three commands ago.
Dependencies (on Debian Linux): libc, libtinfo.

2.2. bash

A similar basic configuration:


Globbing: cd */*oo* moves into "shelltest/Foo".
Tab-completion: cd sh<tab>f<tab> moves into "shelltest/Foo". Good.
History:
- Ctrl+R sh<Enter> performs cd shelltest/Foo out of the box - no configuration needed.
- !! brings back the previous command.
- !-3 brings back whatever was three commands ago.
Dependencies (on Debian Linux): libc, libtinfo, base-files, debianutils.

2.3. mksh

Again, I try to bring this shell to the same level as the others in my small test:


Globbing: cd */*oo* moves into "shelltest/Foo".
Tab-completion: cd sh<tab>f<tab> fails. Case-insensitivity is not in mksh.
History:
- Ctrl+R sh<Enter> performs cd shelltest/Foo out of the box - no configuration needed.
- fc -s -- -1 brings back the previous command (no built-in shortcut).
- fc -s -- -3 brings back whatever was three commands ago (no built-in shortcut).
Dependencies (on Debian Linux): libc. Nice.

2.4. ksh93

It is safe to assume that most of what occurs with the mksh was directly or indirectly taken from the ksh... or was it? At least the completion commands need to be set up first:


Globbing: cd */*oo* moves into "shelltest/Foo".
Tab-completion: cd sh<tab>f<tab> fails. Again, there seems to be no built-in way to circumvent this which does not involve writing my own cd command.
History:
- Ctrl+R sh<Enter><Enter> - yes, that's twice - performs cd shelltest/Foo out of the box - no configuration needed.
- fc -s -- -1 brings back the previous command (no built-in shortcut).
- fc -s -- -3 brings back whatever was three commands ago (no built-in shortcut).
Dependencies (on Debian Linux): libc, binfmt-support.

3. Conclusion

I'll move on to the tcsh over the following weeks.

4. Afterword

... sorry, this has become somewhat longer than I had planned, again. You are happily invited to not have read it because of that. (All later edits were grammar fixes.)