Honestly one could argue that DOS has some merit beyond Unix. It’s simple command line interface expects users will program in other languages like C or assembly. It’s more directly interaction with the machine. Sure it had limitations like file name lengths etc back in the day, but I think many Unix shells are overly complex and ought to yield to more suitable languages like Perl.

Agreed in general, however shell languages (should) have a different focus, such as running processes.

There's been a few attempts at this, but I settled on the fish shell as it has a good balance and syntax highlighting for interactivity.

I still write simple scripts in sh and complex ones in Python however.

Many of the standard unix tools are not written in sh. They're written in C. Am I missing something in your comment?

> It’s simple command line interface expects users will program in other languages like C or assembly.

I think the point here is that DOS explicitly rejects the composition that pipes enable, in exchange for the ability to just hand "the whole system" over to a programmer.

DOS had pipes since version 2.0 I believe.

But the main point, that DOS was basically a thin program loader that "got out of the way" is sound. Think of it like a UEFI shell environment, with 640k+ limits.

Dos pipes were just writes and reads to temporary files. No parallel processes

Ok, but didn't concern the end user, as far as I can remember.