[nextaccountic]

I would recommend Oil!

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

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

[nerdponx]

FWIW this is also the main selling point of Zsh. I should go through this document in detail (thank you for linking it!) but a quick search shows that Zsh is not mentioned even once, and I think a Zsh comparison would be really valuable for people like me.

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?

[nextaccountic]

Well I actually use zsh (I always mean to switch to oil though), and.. in zsh, you don't need to quote variables? Are you sure?

Oh.. I just tested here. It works!

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

And in bash:

  $ 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

The weird thing is, my shell is zsh but my shell scrip ts are all either #!/bin/bash or straight #!/bin/sh, so I never took advantage of this

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

[nerdponx]

The only thing to keep in mind about Zsh parameter expansion is that unquoted empty values will be dropped entirely, while quoted empty values will be treated like the empty string '':

    show_nargs() { print $# }

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

So it doesn't completely solve the need for defensive quoting, but at least it mitigates the need for the most part.

[BoppreH]

Ouch, that is a sharp corner:

    $ 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.

[nextaccountic]

cp itself should have been two commands, or at least accept two flags for those two very different semantics.

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.