The "vaunted Unix Philosophy" has been intellectually and pragmatically bankrupt for decades.

https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook

http://www.art.net/~hopkins/Don/unix-haters/BarfBag.gif

https://web.mit.edu/~simsong/www/ugh.pdf

Preface

“I liken starting one’s computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your
body is covered with lice and flies, you are malnourished and you
suffer from numerous curable diseases. But, as far as young East
Africans can tell, this is simply the natural condition and they live
within it. By the time they find out differently, it is too late. They
already think that the writing of shell scripts is a natural act.”

— Ken Pier, Xerox PARC

The Shell Game, p. 149

Shell crash

The following message was posted to an electronic bulletin board of a
compiler class at Columbia University.

Subject: Relevant Unix bug
October 11, 1991

Fellow W4115x students—
While we’re on the subject of activation records,
argument passing, and calling conventions, did you
know that typing:

!xxx%s%s%s%s%s%s%s%s

to any C-shell will cause it to crash immediately?
Do you know why?

Questions to think about:

• What does the shell do when you type “!xxx”?

• What must it be doing with your input when you type
“!xxx%s%s%s%s%s%s%s%s” ?

• Why does this crash the shell?

• How could you (rather easily) rewrite the offending
part of the shell so as not to have this problem?

MOST IMPORTANTLY:

• Does it seem reasonable that you (yes, you!) can bring what
may be the Future Operating System of the World to its
knees in 21 keystrokes?

Try it. By Unix’s design, crashing your shell kills all your processes and
logs you out. Other operating systems will catch an invalid memory reference
and pop you into a debugger. Not Unix.

Perhaps this is why Unix shells don’t let you extend them by loading new
object code into their memory images, or by making calls to object code in
other programs. It would be just too dangerous. Make one false move
and—bam—you’re logged out. Zero tolerance for programmer error.

The Metasyntactic Zoo

The C Shell’s metasyntactic operator zoo results in numerous quoting
problems and general confusion. Metasyntactic operators transform a command
before it is issued. We call the operators metasyntactic because they
are not part of the syntax of a command, but operators on the command
itself. Metasyntactic operators (sometimes called escape operators) are
familiar to most programmers. For example, the backslash character (\)
within strings in C is metasyntactic; it doesn’t represent itself, but some
operation on the following characters. When you want a metasyntactic
operator to stand for itself, you have to use a quoting mechanism that tells
the system to interpret the operator as simple text. For example, returning
to our C string example, to get the backslash character in a string, it is
necessary to write \\.

Simple quoting barely works in the C Shell because no contract exists
between the shell and the programs it invokes on the users’ behalf. For
example, consider the simple command:

grep string filename:

The string argument contains characters that are defined by grep, such
as ?, [, and ], that are metasyntactic to the shell. Which means that you
might have to quote them. Then again, you might not, depending on the
shell you use and how your environment variables are set.

Searching for strings that contain periods or any pattern that begins with a
dash complicates matters. Be sure to quote your meta character properly.
Unfortunately, as with pattern matching, numerous incompatible quoting
conventions are in use throughout the operating system.

The C Shell’s metasyntatic zoo houses seven different families of metasyntatic operators.
Because the zoo was populated over a period of time, and
the cages are made of tin instead of steel, the inhabitants tend to stomp over
each other. The seven different transformations on a shell command line
are:

Aliasing alias and unalias
Command Output Substitution `
Filename Substitution *, ?, []
History Substitution !, ^
Variable Substitution. $, set, and unset
Process Substitutuion. %
Quoting ',"

As a result of this “design,” the question mark character is forever doomed
to perform single-character matching: it can never be used for help on the
command line because it is never passed to the user’s program, since Unix
requires that this metasyntactic operator be interpreted by the shell.

Having seven different classes of metasyntactic characters wouldn’t be so
bad if they followed a logical order of operations and if their substitution
rules were uniformly applied. But they don’t, and they’re not.

[...followed by pages and pages of more examples like "today’s gripe: fg %3", "${1+“$@”} in /bin/sh family of shells shell scripts", "Why not “$*” etc.?", "The Shell Command “chdir” Doesn’t", "Shell Programming", "Shell Variables Won’t", "Error Codes and Error Checking", "Pipes", "| vs. <", "Find", "Q: what’s the opposite of ‘find?’ A: ‘lose.’"]

My judgment of Unix is my own. About six years ago (when I first got
my workstation), I spent lots of time learning Unix. I got to be fairly
good. Fortunately, most of that garbage has now faded from memory. However, since joining this discussion, a lot of Unix supporters
have sent me examples of stuff to “prove” how powerful Unix is.
These examples have certainly been enough to refresh my memory:
they all do something trivial or useless, and they all do so in a very
arcane manner.

One person who posted to the net said he had an “epiphany” from a
shell script (which used four commands and a script that looked like
line noise) which renamed all his '.pas' files so that they ended with
“.p” instead. I reserve my religious ecstasy for something more than
renaming files. And, indeed, that is my memory of Unix tools—you
spend all your time learning to do complex and peculiar things that
are, in the end, not really all that impressive. I decided I’d rather
learn to get some real work done.

—Jim Giles,
Los Alamos National Laboratory