Re:Bash $* and $@ (2017)
by lukeschlather on Sunday January 12, 2020 @08:22PM
(#22031092)
I've been writing a lot of Powershell lately, and my only real gripe with it is that it seems suspiciously like not being Posix compliant in any way was a design goal.
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.
Major backwards-incompatible update have come recently (Powershell Core).
What did they break? Powershell core just doesn't include Win32, but that's fine, it runs on Linux and macOS and they don't need Win32.
Powershell 7 has a full Win32.
I.e. curl command now means actual curl, not Invoke-webrequest
Re:Bash $* and $@ (2017)
by fiddlerwoaroof on Sunday January 12, 2020 @04:58PM
(#22029811)
If you haven’t tried scripting in zsh, I’d give it a go. zsh has a lot of safety improvements and quality of life features.
It's also subject to many of the same footguns as Bash so I'd put that into the 2nd camp (re my previous post).
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.
Re:Bash $* and $@ (2017)
by fiddlerwoaroof on Sunday January 12, 2020 @05:22PM
(#22029978)
> Zsh had arrays from the start, and its author opted for a saner language design at the expense of backward compatibility. In zsh (under the default expansion rules) $var does not perfom word splitting; if you want to store a list of words in a variable, you are meant to use an array; and if you really want word splitting, you can write $=var.
Re:Bash $* and $@ (2017)
by fiddlerwoaroof on Sunday January 12, 2020 @05:21PM
(#22029969)
I realize that it has similar footguns, however reading through their info pages, I was surprised by how many they just decided to fix, unless you explicitly turn on compatibility mode.
What are your thoughts about fish?
Re:Bash $* and $@ (2017)
by fiddlerwoaroof on Sunday January 12, 2020 @04:59PM
(#22029820)
Does fish still have the issue where pipelines aren’t really concurrent?
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).