I use OpenBSD ksh as login shell on all my machines except the gaming pc, haven’t seen any issues

In the past I replaced Bash as the default POSIX shell interpreter /usr/bin/sh with Dash. Normally the /usr/bin/sh is run by Bash in compatibility mode, if no Bash features are needed. Dash is an independent implementation of /usr/bin/sh compatibility and in theory should startup a little faster than Bash for those scripts. In practice I didn’t notice any difference on my modern computers (and I mean more than a decade old by now). My personal experience and recommendation is not to worry about this and not install Dash at all. If you do, nothing will break or get worse, but I believe nothing is won either.

Dash as an interpreter for /usr/bin/sh is only for shell scripts, that run the shell in default mode without Bash or other features. It is not intended for use in the terminal in an interactive manner.

Learning Bash? Oh hell yeah! The language is a bit ugly and has really lot of pitfalls and dumb language constructs or default behavior. But it is the default and you can rely on Bash for the most part in Linux. You can write scripts, understand others scripts and make changes to them. And it is even used in the IT industry everywhere (well maybe not everywhere…). But that’s not all, you have to learn Linux stuff too, not just the scripting language to make most use of it. While Bash the language itself is ugly, it is still useful to learn the basics and get into it a bit deeper over time. I fully recommend it.

As you’ve mentioned in other threads, bash is a hard requirement for the OS, so if it’s already installed, and the default on most Linux distros, bash is probably the best option.

The dash shell isn’t designed to be user interactive. It’s a lightweight scripting shell/language.

The ksh shell is an older standard shell. Years ago I worked for a company that ran corporate Unix systems and on those systems only ksh and tcsh were available. Ksh was the default, and as someone only familiar with bash it was a bit different but mostly the same. So there is at least one point for maybe choosing ksh.

However my personal shell preference is zsh. When I write scripts I do so using bash. The two shells are 99% similar on a day to day basis, but I prefer zsh for a user interface. So I use one for day to day and the other for scripting.

Other threads have also mentioned fish, which is also a great choice if you don’t know where to start.

Are zsh or fish “heavier” or “bloated”, maybe. But remember to consider your attack surface. If your house is on fire it doesn’t matter of you fix the leaky faucet in bathroom or the kitchen.

Bash is 10-16KB of ram, dash is 3-5KB of ram. Does it really matter at that point?

Debloating a system for a tiny appliance device is worth it. Debloating on a machine with a modern processor, 16-64 GB ram and a TB harddrive is not necessary. You may not even notice a difference.

But if you enjoy that stuff, go for it.

I have only used KSH for a proprietary software install that needed it, it didn’t feel much different than working in a BASH shell.

You do not want to use dash interactively! It is created solely for scripting and not for creature comfort. This means all the stuff you’re probably used to such as line editing and command history will not be available.

At some point, you’d want to ask yourself how heavy is “heavy” and how much stuff are you willing to shed? Do you not need tools such as web browser, media player, or office suite? Are you willing to get rid of desktop environment?

In the extreme, you can remove all the documentations, all the manpages to save space. You can even remove all the localization files, without which stuff would look weird, but would still run.

Further than that, you can even customize your kernel, opting out all the drivers you don’t need, or even some that you could use (e.g. wifi, audio, hardware monitoring). Next, some kernel features that are less essential such as statistics, logging, and debugging, as well as the handling for some network protocols. If you wanna go crazy, you can enable the expert/embedded options and with that you can disable stuff that can be critical (e.g. error reporting, certain IPC feature).

It’s a rabbit hole, really.

I don’t have any answers, just my own experiences. Last year I decided to use Alpine Linux as my Operating System for a couple of self-hosted things running on a Raspberry Pi. I chose it because it’s super minimal and used less common tools (for example doas instead of sudo). That unintentionally forced me to learn how to use Linux using more basic commands that are more likely to be available on other Linux systems.

Alpine Linux uses Busybox-Ash which is a POSIX compliant shell that’s very small and very basic. The scripts I ended up writing tend to be POSIX portable meaning that they should work on a wider variety of systems. That comes at the cost of script simplicity and readability as well as missing out on many features that make Bash scripts more complex, robust and easier to work with.

I have a working example POSIX portable script. I’ve been adding to it all the things I’ve learned. You can check it out here if you’re interested.

I use Alpine Linux with Sway as my daily driver but still keep a copy of Linux Mint DE ready to use because it’s nice to have a fully featured work environment for the days I don’t want to think.

I have been using Dash for years now as bin/sh. I couldn’t manage to get rid of Bash so it’s still installed (distro is Artix). As an interactive shell I run Fish. Dash is indeed rather terrible as an interactive shell as others have said.

Ignoring the interactive features (or lack thereof) in dash/ksh, removing bash is not really something that’s possible on most distros (excluding Alpine and possibly Debian) since it’s used in scripts everywhere. And if you need to have bash installed anyways, why opt for the less pleasant shell in daily usage?

I do write my scripts in POSIX sh, more for compatibility sake. But shells like dash, mksh, are not made for interactive use, they lack most not-really-convenience features.
But heavy, that’s only invocation time; it mathers more if you do things like 100 awk calls (that one is heavy to invoke) per line you parse.

Though i did write my own cross-shell session scripts, centering on the ENV variable which most shells understand (and a /etc/bash/bashrc loading it, since Bash doesn’t).
Again, more because i think, why load xkb maps 3 times in 3 scripts if you can do it only once? And most session scripts look like they were never touched the last 20 years. And then a if you do it, do it right mindset.

Worth learning; i think so. You learn, with time, more about how to use shorthands and functions, to structure your scripts nicely, instead of doing if if if messes more “convenient” shells lead you to. Which benefits you in real programming languages too and leads to more readable and better maintainable scripts.
And the only times i miss convenience features like arrays is in 500+ loc scripts which would have better been done in python. Btw, don’t do 500+ loc shell scripts: they do become a maintenance mess even if you do everything right.

Edit: right, i forgot the POSIXLY_CORRECT env variable. Some AUR setup-scripts have issues with a forced POSIX shell.

I agree with the idea of debloating and hardening your systems.

It helps to have some context as the approach I would take depends on what kind of system I’m running. I think its also good to identify your priorities to hone your approach.

When I want stability, fast security updates, minimal install size, I usually use Alpine which indeed uses the lighter busybox bin/sh instead of bash.

When it comes to my workstation shell I’m more focused on utility than size. So bash or zsh or fish, or whatever you find the most useful, makes sense to use.

Dash really sucks. Use it as an interpreter for /bin/sh and thats it

Alacrity or die

See comment below.