I think zsh and others (bash, ash, etc) are a problem for many reasons: 1. Poor start-up time. It's not so much a problem if you are opening a terminal, but if

I think zsh and others (bash, ash, etc) are a problem for many reasons: 1. Poor start-up time. It's not so much a problem if you are opening a terminal, but if you're running shell scripts in a large loop, they could soon become a significant factor of your run time. 2. Too much RAM. I'm looking at my server and bash is taking 2-3MB per script. When you're running a 10's or maybe 100's of little scripts this really adds up. 3. The syntax is wrong. For example in bash, there are more ways to write a loop that I can to mention. Often I find myself wondering if I need no brackets, [], [[]], (), (()) - it really shouldn't be this hard or varied. 4. Proper types. Sometimes you simply don't know if what you have can be parsed as an array or not, or whether you have a string representation of a number. I haven't yet thought of a better way though. For example, it does a few things right: 1. Piping is really powerful. Where possible I use '|' as it's usually the simplest to understand, when you have multiple arrows < > with numbers on the end it can take a moment to figure out what gets passed where. 2. 'Forking' is super simple. Just throwing an '&' at the end means the command no longer blocks, super cool. I think I would like to see some form of "join" and I know this is possible, but it would be cool if there was a super simple syntax for this too. Maybe: pid=$(some command &) # & would return a PID number # some time later join $pid # How would you know if the PID wasn't re-used? 3. No compilation is great for writing scripts and maintaining portability. 4. The completion saves loads of time. Being able to type 'ls' and tab a few times is great for finding where something is or an option for a command. In the same strength, the history accessible with arrow keys is also really cool. One thing that could save some time during startup is to have a spare shell already spun up and waiting to be allocated. This would cause some issues with sourcing, but it could be possible to check the timestamps on the sourced files and see whether they require another source just before handing the process over. It's a little hacky though and a better solution would still be to address the performance issues directly.