Weekly Journal 27 - Shells, Planning
Thinking about changing my default shell, but I am not sure if it is worth the hassle. Also a brief mention of the fallacy of trying to plan a full delivery schedule.
I am a huge fan of working from the Linux terminal. I love the feel of CLI tools and typing in commands, and ability to combine various CLI tools together with small scripts. Over the past several years, new shell options have appeared on the scene that are drastically different from the usual suspects like bash and zsh.
My current favorite shell is zsh. It brings more power and customization than bash provides, namely around things like colored text, completions, and fancy prompts. While bash can do most of these things now, it generally feels slower and a little bit awkward when doing these things in bash. The nice thing is zsh does all these things, and remains almost fully compatible with bash and sh. This means that just about any POSIX-compatible script out there will run as-is without requiring any changes.
In spite of my love of the fancy things zsh can do, in general I am not a big fan of building custom configurations. I try to keep my configuration fairly stock, which makes it easier to jump between systems. I lean on addons like Oh My Zsh and Starship to enable those advanced features without sinking hours and hours into building my own custom configuration.
The New Shells
With that as a backdrop, I have been looking at some of the alternative shells that have popped up recently. These shells come with all kinds of new functionality, but at the cost of backwards compatibility.
The first I have been looking at is fish. The fish shell is interesting because it comes with all the bells and whistles, and has them enabled by default. This means completions, color highlighting and other things work immediately without the need to edit configuration files or install a plugin framework. It also has a more refined scripting language when compared to bash. For better or worse, the sh scripting language is awkward and confusing to use, even with practice. The downside is it does not work with “standard” bash scripts. Any script that you might find on the internet, or that ships with a software project will need to be rewritten in the fish scripting language.
The second shell the kind of caught my eye is Nushell. Nushell is interesting because it treats all output as data. Even simple operations like running
ls to view a directory becomes structured data in Nushell. This makes it incredibly easy to build pipelines that can import and manipulate all kinds of data. Again, the major downside is that it will not run standard sh/bash scripts. I am not sure I would use something like this as my default shell, but it might be something I would use to build data pipelines when I do not the full power of something like Python, and I do not want to fool around trying to parse and massage data in bash.
The final shell on this list is Microsoft’s PowerShell. PowerShell has been the new default shell in Windows for some time now, but a few years back Microsoft released a cross-platform version that runs on Linux too. Similar to Nushell, PowerShell has built-in support for working with data. For example, it has native support for working with most common data formats like JSON, CSV and XML. It also has a nice object-oriented programming language that integrates nicely with .NET libraries. The overall feel of the shell reflects its Windows heritage, but once you get past some of that it is a very nice shell to work with. Again, it will not run bash scripts, so you will be stuck with either shelling out to bash or rewriting existing shell scripts.
After poking around a bit, I think I am going to stick with my zsh + Oh My ZSH + starship setup as my default. For the time being I think I find more value in the ability to run existing scripts than in the new functionality that these shells provide. However, I think I may install Nushell and PowerShell and look at using them for specific tasks that play to their strengths.
This is more of a rant than anything. I wish more product and sales teams would understand that you can’t plan every available minute in a given time span for work. You have to leave space for innovation, cleanup and unforeseen challenges. If you start out with a completely full plan, you are going to waste time having to update the plan when some challenge pops up that disrupts the initial schedule. No matter how hard you try, you can’t put ten pounds of sugar into a five pound bag. It just doesn’t work. Similarly if you don’t leave time for innovation and cleanup, the code that gets shipped will have large amounts of technical debt.
Anyway, enough of that for now.
I discovered a different way to implement my APIBan tool, so I hope to get a chance to look at that this week.