1. more emphasis traditional programming paradigms (be it JS, LISP, Python, whatever) which leaves a platform that is arguably a better designed language but however is a poorer REPL environment for it. Bash works because it's terse and terseness is actually preferable for "write many, read once" style environments like an interactive command prompt.

2. or they spend so much effort supporting POSIX/Bash -- including their warts -- that they end up poorer scripting languages.

I think what we really need isn't to rewrite all our shell scripts in Python but rather better shells. Ones which work with existing muscle memory but isn't afraid to break compatibility for the sake of eliminating a few footguns. Shells that can straddle both the aforementioned objectives without sacrificing the other. But there doesn't seem to be many people trying this (I can only think of a couple off hand).

I agree with the idea of breaking backwards compatibility, but Powershell honestly has enough core design issues that it itself is starting to feel like it needs a major backwards-incompatible update.

Powershell 7 has a full Win32.

https://news.ycombinator.com/item?id=22029662

Not that I'm taking anything away from zsh. It is a nice shell. But I think we can do even better considering how dependant we still are on shells for day to day stuff.

https://unix.stackexchange.com/a/26672

Best of all though, it's absolutely compatible wherever you need to run it.

I mean, I would expect the syntax to be something like:

    make >/dev/null 2| more

    Note that the order of redirections
    is significant.  For example, the 
    command

    ls > dirlist 2>&1

    directs both standard output and 
    standard error to the file dirlist, 
    while the command

    ls 2>&1 > dirlist

    directs only the standard output to 
    file dirlist, because the standard
    error was duplicated from the 
    standard output before the standard 
    output was redirected to dirlist.

Can it be memorized? Yes, because it is just a single 'incantation': "2>&1". Just put that redirection operator before the redirection of the standard output to the file, and the result is stdout goes to the file, stderr goes to the pipe.

  Note that the order of redirections is significant. For example, the command

  ls > dirlist 2>&1

  directs both standard output (file descriptor 1) and standard error (file descriptor 2) to the file dirlist, while the command

  ls 2>&1 > dirlist

  directs only the standard output to file dirlist, because the standard error was made a copy of the standard output before the standard output was redirected to dirlist. 

"Redirecting streams" winds up being confusing - it's all just `dup2`.

Yes, I know that underneath it's all calls to `pipe()` and `dup2()`, which I can do (and have done) in a language other than shell. It's the shell redirection syntax (for anything more complex than simple redirection or a pipe) that just doesn't make sense to me.

    command 2>&1 > >(cat - | cat - > fd1) | cat - | cat - > fd2

How to read this:

When Bash sets up the file descriptors for 'command' it initially makes descriptor 1 refer to the pipe, and descriptor 2 refer to the terminal.

So, the dup operator (2>&1) copies the fd in descriptor 1 (which is the pipe) into descriptor 2 (so after the dup operator is processed both stderr and stdout for command reference the pipe).

Next descriptor 1 is replaced (the > operator) by a reference to a fifo created by the process substitution operator (the >(...) operator).

So now command's descriptor 1 refers to the fifo created by >() (which itself contains a "string of commands").

Then, because stderr for command was made to be a copy of what was previously stdout (before modifying stdout) it continues to refer to the pipe Bash setup (the | operator), and stderr now flows out over the pipes to another "string of commands".

    ( echo "stdout"; echo "stderr" 1>&2 ) 2>&1 1>/dev/null