http://www.oilshell.org/release/latest/doc/idioms.html

It removes the need to quote every variable, and this is fantastic

Or is it like Neovim vs. Emacs at that point, where neither one is "better" and it's just a matter of taste and/or whichever one you happened to try first?

Oh.. I just tested here. It works!

  $ mkdir -p /q/a\ b/x
  $ a="a b"
  $ ls /q/$a
  x

  $ a="a b"
  $ ls /q/$a
  ls: cannot access '/q/a': No such file or directory
  ls: cannot access 'b': No such file or directory

Anyway, I want to link also to

http://www.oilshell.org/release/latest/doc/upgrade-breakage....

http://www.oilshell.org/release/latest/doc/warts.html

http://www.oilshell.org/release/latest/doc/known-differences... <- here it talks about zsh a bit

    show_nargs() { print $# }

    q=
    show_nargs $q    # 0
    show_nargs "$q"  # 1

    $ echo 'aaa' > a.txt
    $ echo 'bbb' > b.txt
    $ TMP_DIR="" # Mistake! Missing arg, failed search, typo'd name, etc.
    $ cp a.txt b.txt $TMP_DIR
    $ cat b.txt
    aaa
    $ # The contents of b.txt are lost.

Actually there's a wave of unixy tools being written in Go and Rust and I think there might be a suitable cp replacement already, but it's up to distros to package it.

PERL. Sh, awk, sed and mini-C all at once.

Traditional shell scripting languages are great at exactly three things: typing commands interactively, running other programs, and sourcing other shell scripts. They are also is distinct in that they are "stringly-typed" (i.e. everything is a string), and moreover that syntactically bare symbols are also strings.

Typing commands interactively is essential because... it's a shell. That's what it's for. Most programming languages do not and should not optimize for this. But it's literally the purpose of a shell, so a shell should be good at it.

"Running other programs" includes invoking them (literally 0 extra syntax), piping them (one letter: |), and redirecting the standard input and output streams to files (>, <, <<, etc.). This is one of the great innovations of Unix and nothing holds a candle to its elegance and convenience, even if sometimes we get frustrated that pipes are "dumb" streams of bytes and not something more structured.

"Sourcing other shell scripts" practically isn't much different from "running another shell process", except that source'd shell scripts can set shell parameters and environment variables, which is an important part of e.g. the X11 startup system: the global /etc/X11/Xsession script sources the user's ~/.xsession script, so any environment variables set in the latter are propagated to the former, and thereby are inherited by the X11 window manager when it eventually starts. If you wrote the /etc/X11/Xsession script in any other programming language, you'd have to inspect the environment variables of the ~/.xsession process and "merge" those values back into the current process' environment.

On being stringly-typed, I think it's mostly good in the context of the "two things that it's good at" described above. It cuts down on syntactical noise (otherwise "everything" "would" "always" "be" "quoted" "everywhere"), makes string interpolation painless, and generally supports the "typing commands interactively" use case. Make and Tcl are the only other popular languages in this category. Perl and Ruby allow it in specially-delineated areas of code. Moreover, Bash, Ksh, and Zsh all have arrays, which helps fix some of the biggest problems of everything being a string.

In short, if your program can make good use of the above features, then a traditional shell is a great choice. If you program does not need those features, do not write your program using a shell script, because shell languages are awkward at best in pretty much all areas.

And if you are considering an "alt" or "neo" shell language, in my opinion it must excel in the above two categories. Being stringly-typed is a matter of taste, but the language should also probably support bare-symbols-as-strings and string interpolation.

Python, for example, is not a good shell scripting language because it is not easy to type nontrivial commands interactively, it lacks tidy syntax for input/output redirection (even though it's actually pretty easy using the standard library), and it lacks bare-symbols-as-strings. So instead of:

    #!/bin/sh
    foo -x 1 -y 2 "$ABC" | bar --json -

    #!/usr/bin/env python3
    import os
    from subprocess import Popen, PIPE, run

    foo_cmd = ['foo', '-x', '1', '-y', '2', os.environ['ABC']]
    bar_cmd = ['bar', '--json', '-']
    with Popen(foo_cmd, stdout=PIPE) as foo_proc:
        foo_proc.stdin.close()
        run(bar_cmd, stdin=foo_proc.stdout)

Please add another standard output stream.

stdout is for output

stderr is for error messages

stdlog for status/tracking, verbose output, event streams. Too often this gets shunted to stderr, and I don't want to logfile hunt. Other examples: download status from curl, verbose output flags in things like ssh and other comm programs that need configuration debugging on the regular, and others.

Nushell seems to also focus on json output for commands. I think this should be a requirement pushed into all unix commands that do output (LS! please please please a json output flag for simple ls which CANNOT BE PARSED RELIABLY).

  `template${Math.random() > 0.5 ? 'strings' : 'literals'} have beern part of the language since 2015!`

    $E:HOME'/.local'