Bash (Bourne-Again SHell) vs Kubernetes

In Bash, exceptions are the rule, not even all being described by the main page.

There are a grand total of 5 different ways of quoting, sometimes even when one does not want to, for instance in command substitutions. These are all based around preserving the literal meaning of every character, with an exception list. There is even an exception list to the exception list in 4 of the 5, regarding how the backslash behaves! The behavior of the backslash is also one of the quoting rules, so naturally, it also has an exception in how it works when it stands before a newline as compared to other characters.

Bash has several layers of interpretations, all to be kept in mind:

The ~ expands to the home of the current user. So if you store it in a variable, can you use it that way? Nope: tilde expansion comes before variable expansion.

Aha, so that's how it works! Then, since applying quotation happens after redirections are set up, it must mean that redirecting within quotes works, right? Nope: there is an exception! If a redirection symbol is not quoted, quotation around the symbol is observed, but is not removed. So, since variable expansion also comes after setting up redirections, and no exceptions are described here in the man page, getting the name of a file from a variable and using it as a target should not work, right? No: redirection does not actually take place when the symbols are being read, the symbols are merely removed and are noted for later, right before when the actual command runs.

Apart from 5 types of quotation, there are basically 2 quoting phases, 2 word splitting phases (with only one being controllable), and a tokenization phase on top of that.

If you have a command, it could be an alias, a special built in, a non-special built in, a symbolic link to a file, a regular file, a function, with different rules regarding how they can be overridden, if redirection happens before or after arguments have been passed (what does "time my_command 2>&1 >log_file" do?), etc.

This list is admittedly long, but it doesn't even scratch the surface of the bloat, complexity and inconsistencies of Bash.

Apple, one of the largest distributors of UNIX systems, only ships an ancient version of bash that predates the iPhone.

No one knows why as Apple hasn't said, but the version Apple includes in MacOS is from right before the license was updated to version 3 of the GNU GPL (General Public License). Other major companies (IBM, Microsoft) have had no problem shipping the latest version of bash, so it's unclear what Apple's lawyers are averse to. The GPL has always said that if you distributed a program, you granted everyone the right to use it freely. The biggest change in version 3 was the addition, "...and that includes software patents."

This was necessary because back in 2006 Microsoft was demanding that any company that uses Linux pay them or get sued for infringing on their patents. They even took some companies, like TomTom, to court. No software which can be restricted retroactively like that is truly free, so GPL 3+ includes a clause saying that if you distribute the program, then you are also granting license to any patents you own that are necessary to run it.

What patents Apple has that bash could possibly infringe on is a mystery, but the bigger question is, Why does Apple even care? So what if they are granting people the right to run bash without being sued by Apple. It's not like they were planning on doing that, right?

Even though it is not bash's fault that it is not Apple Lawyer-approved, this is a CON for it because a lot of people use Apple products. While there are methods like brew to install a current version of bash, Apple does not make it obvious to their customers what they are missing.

One of bash's claims to fame is compatibility with previous versions of itself and historic shells. But, doing that means that new features are often written in tortured, awkward syntax that is not easy to learn. For example, bash uses the POSIX way of doing arithmetic: to add 5+3 you must put the numbers in double parentheses with a dollar sign at the start: x=$((5+3)). It is true that many shells suffer from this same CON, but since bash is such an important shell, it has less wiggleroom to ditch clunky ideas that might break existing scripts.

People who wants power features or to customize their shell experience use zsh or fish.

filename expansion is not consistent. "echo *" will print the names of the files in your current dir, if there are any... and will print "*" if there are none.

If there are no .sh files, this will print mask itself:

for filename in *.sh; do
    echo $filename
done

To have command autocompletion in bash you need to install third-party plug-ins.

What it is mostly used for are file system operations. Guess what it is bad at? Operating on files. It automatically splits and carries out filename expansion on every single string resulting from variable expansion and command substitution unless quoted, by default on whitespace, whilst spaces are very common in filenames.

Before that, it even does pathname expansion, so woe to anywone who does not want to actually operate on files, but has a globbing metacharacter stored anywhere in a variable.

This means what you store in a variable is not going to be what will ACTUALLY be accessed.

If an empty variable is unquoted, it disappears completely due to word splitting, sometimes leading to applications signalling a missing parameter at a wrong position.

If quoted however, said variables cannot be iterated over in a loop, no matter what character one uses for word splitting.

If you use any globbing pattern with a command, be sure to use -- after the option arguments or if none are present, before starting the pattern with a mandatory ./

Otherwise, another Bash script run gone wrong or a hacker can create files named like an option ("-f", for instance) and your program will happily accept it as such, if it results from globbing.

For interactive use, it is convenient. For programming, it is a no-go.

Kubernetes was not written for docker clustering alone. It uses a different API, configuration and different YAML definitions. So you can't use the Docker CLI or Docker Compose to define your containers. Everything has to be done from scratch.

Windows compatibility rules, the host OS version must match the container base image OS version. Only Windows containers with Windows Server 2019 are supported. Also other restrictions are present.

Because of how opinionated Kubernetes is, it may be necessary to change some things if you decide to use Kubernetes as an orchestration tool in an existing application.

It happens that a Pod needs a manual kick before it runs properly, especially if you're near full utilisation of your machine resources. Sometimes it is just a long delay.