TL;DR

As a software developer, you need to understand that while you may have the need to develop your software in the context of a POSIX standards compliant shell (bash, csh, tcsh, etc.), to make sure that it works in production on POSIX compliant systems, that doesn’t mean that your development environment (read workstation) needs to be limited to those old shells. You should modernize your development environment to use newer shells, such as Fish or Nushell, to go along with that new workstation hardware that you continually upgrade (or do you still use 1970s/1980s hardware to go along with those old shells? Yeah, I didn’t think so.), and reap other development productivity benefits!

Brief History of command-line interfaces

The history of command-line interface programs, shells, is a very long history. Instead of attempting to re-write it here, I am going to direct you to go read this.

My history with shell programs started off with the Bash shell, binary file being bash or sh, when first learning Linux early in my life, and through most of my career (still going today).

Up until 2019, my experience with shell programs at a personal workstation level were always using Bash, when then the Catalina (10.15) version of macOS adopted the Zsh shell as the default login shell, and I also adoped it as my personal shell of choice.

Below are my terminal and shell setups overtime…

-2019

  • Terminal (default terminal app in macOS)
  • Bash shell

This is as a basic as you can get, as a result, no screenshot to share.

2019-2020

terminal_zsh_omz

2020-2022

iterm_zsh_omz

Current

iterm_fish_tide

Future

No screenshot here to show (yet).

I am particularly excited about moving to the Nushell shell some day. In particular, and if you have read some of my previous posts this shouldn’t come as a surprise, I am exited about the Nushell support for parallelism, read more about it here.

That is all. Thanks for reading.