Pretty much every RDBMS on the planet (and some no-SQL databases too). :)

I jest but I do agree that Bash et al have their warts. Seriously obscene warts that only make sense when you look at the language from the content of 40 year old systems. But these days there are other options if you want the power of a command line but without (most of) the warts of traditional shells.

A circular saw can easily ruin a piece of work if your not careful, and it could even chop off your hand. We don't tell carpenters that they shouldn't use saws because they are dangerous. There are lots of jobs that are work with dangerous tools.

If a manufacturer could easily design the circular saw to be safe (á la SawStop) with little added cost, but decided not to, I think most people would consider them grossly negligent.

Huh.

I didn't know about SawStop before, so your comment sent me on a wiki-hunt.

"Gross negligence" seems like a huge understatement for all the rationalizing and lobbying manufacturers did to avoid having to use safety technology.

https://en.wikipedia.org/wiki/SawStop#Opposition_from_trade_...

A saw is <<hard>>ware, a physical thinghard to change and improve, while a shell is <<soft>>ware, supposed to be easy to change and improve.

"Not to mention how dangerous it is to use. Accidentally type the > symbol? Enjoy overwriting whichever file came after in the command."

At least in zsh, you can prevent such mistakes by

  setopt NO_CLOBBER

It's saved my bacon many times.

Also, from bitter experience I've forced myself to get in to the habit of never typing:

  rm *

but instead always doing:

  cd ..
  rm foo/*

It forces me to be more conscious of what I'm deleting.

I have `alias rm="echo DISABLED"` in my shell rc, and I have `trash` defined as a big shell function that safely moves stuff to the x desktop trash bin without clobbering anything. It's mildly irritating, but it gives me incredible peace of mind.

> in zsh […] setopt NO_CLOBBER

In Bash it’s

  set -o noclobber

or

  set -C

Those work in any POSIX shell, and also zsh.

It seems you are correct:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

If you are that concerned about this specific problem, shell allows you to "set noclobber" (or "set -C") to not overwrite existing files.

Yup, I only learned about that while writing https://www.oilshell.org ! I'm sure that has been around for decades; shell also has discovery and documentation problems :)

> shell also has discovery and documentation problems

Only because people refuse to read the specification. The POSIX Shell & Utilities volume is exceedingly clear and straight-forward. (I vehemently disagree w/ its characterization in that paper.) It helps if you use the frames-based HTML version to make it easier to navigate and explore the various utilities, and especially to see how the syntax specification is broken down--while that section is short, it's difficult to appreciate without explicitly seeing how the subsections are related.

I only code in POSIX shell because I really can't be bothered to remember all the minutiae of other shells, almost all of which provide strong POSIX compatibility, Bash especially. I've never lamented the lack of arrays; but I regularly wish that POSIX would adopt ksh-style coprocesses so dash would have them. The shell is really all about stitching together processes (including subshell contexts), and coprocesses fill a conspicuous gap in functionality.

I've never used ksh-style coprocesses so I'd be interested to hear about some use cases for them, and what you like about them. Examples would be even better -- I've never seen them, and I've looked at a lot of shell.

Bash has a different implementation of coprocesses that doesn't seem to be used much, and is very limited. I believe there can only be one coprocess active at a time, which is very un-shell-like! I got an e-mail once from someone who was using them, and I felt it could be achieved by other means.

I have a good idea coprocesses in Oil which basically is a startup time optimization. The coprocess will basically take argv over a unix domain socket, and have other commands to change the process state. It solves "the problem of VMs and containers that start slowly".

https://www.oilshell.org/blog/2021/04/release-0.8.9.html#wha...

Unix domain sockets are already used for the headless shell in Oil (more coming on the blog about that)

https://www.oilshell.org/release/latest/doc/headless.html#im...

The simplest description I've found is at https://www.dartmouth.edu/~rc/classes/ksh/coprocesses.html, which also provides a couple of examples.

Basically, you start a coprocess using the "|&" operator:

  somecommand |&

This starts somecommand asynchronously, with stdin and stdout attached to anonymous pipes with descriptor numbers that can be referenced by a literal descriptor name, "p". So running

  cat <&p

will shuttle the output of the somecommand coprocess to stdout.

"p" always references the most recently created coprocess, so to juggle multiple coprocesses you have to dup "p" to explicit descriptors:

  exec 4>&p
  somecommand2 5<&p |&

That's not as great as having named references, but it's rare to need to independently juggle more than 1 or 2 coprocesses from the same context. You're almost always plugging them together in series or in a complex graph using subshells. In either case you're only needing to manage the same few descriptor constants. It's sort of like writing in a stack-based language, where you really only use explicit references to the top of the stack.

coprocesses provide a simple construct for cases where you would otherwise have to manually create a named pipe using mkfifo. The need for this pattern comes up surprisingly often, IME, yet because it's so messy--now you need to worry about /tmp races, cleaning things up, etc--people rarely bother, myself included. From the perspective of a shell it's a relatively simple construct to implement. The semantic benefit/cost ratio is exceptional.

This basic functionality is complemented with extension options to the read and print (non-standard) builtins: -p reads from or writes to the latest coprocess, and -u the specified descriptor number. I haven't used coprocesses much because I can't rely on them, but I don't think these are strictly needed. Maybe they were required for proper buffering in early implementations (or even current ones), where redirection to and from builtins didn't utilize the same buffered I/O context? That seems more like an implementation detail.

ksh93, bash, and some other shells provide the process substitution construct, "<()", which can provide similar capabilities to coprocesses in many cases. But I'm pretty sure anything you could do with process substitution you could do with coprocesses, making the latter the more powerful construct. coprocesses seems like the critical missing primitive from the traditional Unix shell model, and would round it out. (Of course, the sky is the limit for evolving the Unix shell model in new directions, as Oil has shown.)

ksh88 had coprocesses so I'm curious why it wasn't included in POSIX Maybe because bash lacked an implementation? Or incompatible quirks between ksh88 and ksh93 related to stdout inheritance across coprocesses?

Lack of warnings about accidental file overwrite is less of a problem today than say 20-30 years ago: modern filesystems allows to make regular snapshots which help to recover accidentally lost file. It doesn't happen often in my practice, but by doing what told without questions shell saves my time every day.

Well "mastering [that] careless design" has made me farore capable than many of my peers at tasks that involve debugging network problems. I can slice and dice data files with ease and much more speed than any of my associates because the power the shell brings, I have gained a much deeper understanding of how am OS and computing works, what is going on under the hood, and consequently have reaped many advantages due to many hours spent mastering the shell.

You are right it has some warts, but if a file is really that absolutely critical I make a .bak copy of it before I start my work. The shell has its limitations but so do all tools and the power it gives me is unmatched.

As for other popular software there is plenty out there but other popular software out there destroys something far more valuable to me. My time.

>You are right it has some warts, but if a file is really that absolutely critical I make a .bak copy of it before I start my work

This seems to miss the point completely, unless you back up your entire hard disk before running every command. The whole problem is it's easy to nuke things you weren't intending to touch, accidentally.

The user-hostility of the shell is not a required feature to achieve its power. All of the advantages you cite could be had without being a terrible footgun with human factors mired in 1970s computing culture.

How is any of the advantages you listed not achievable by learning a better programming language, say, Python?

Some of them are but for quick stuff it’s hard to match the speed and flexibility of the shell