Why isn't mkdir -p default?

mkdir: cannot create directory ‘/tmp/test/123’: No such file or directory

It happened again - you forgot to create the damned parent directory first. Of course, mkdir can do it with the addition of a paltry -p flag. Now you commit a three-character change and re-run the failing CI job for the eighth time in a row.

I've written quite a few shell scripts in my life. In every case, mkdir -p is the functionality I want, never regular mkdir non-p.

So why not change the default behavior?

The first reason I can think of is changing it could break compatibility. There are untold millions of "mkdir without -p" invocations out there. Some of them are probably depending on that exact behavior in some bizarre way.

The second reason I have is about being intentional and explicit. Maybe the path you're mkdir-ing comes from a variable that was incorrectly set. If mkdir fails on this, whatever operation you were preparing is probably also going to fail instead of running erroneously on the wrong directory.

Generalizing the problem

The point is, it's not just mkdir -p. When something becomes as ubiquitious as mkdir, it becomes hard to change. Even fixing 100% obvious bugs can cause pain for users of that thing.

Think about the Rust standard library for a minute. Often it's accused of lacking common features that other languages include in their standards: http server, hashing, json parser, etc...

Once a feature makes it into the standard library, it becomes basically permanent (we can all try to forget how disasterous the Python2 -> Python3 migration went).

By not including these basic features directly in the standard, Rust is a bit more future-proof. When someone thinks of a better way to do async backends, for example, the community can migrate at its own pace and there isn't a breaking change to the standard involved.