Your link doesn't really counteract this usage. Your stance seems to be a bit like giving up on writing Javascript because of the JS WAT video. All languages have weird corners; bash has more than most because it's so old, and has only reluctantly added real programming language features, but the better you know the programming language, the more you tend to use it on the terminal. And I spend most of my non-editor, non-browser time in the terminal.
I still write bash scripts in preference to Ruby or Python even in less trivial situations, especially when multiprocess orchestration of heterogeneous executables is involved.
I have written some bash scripts myself, but none that were longer than maybe 10-20 lines. Above that, I usually reach for other tools.
Yeah, this is insane and the default settings of bash are quite horrible. You can set some bash options in the beginning to avoid such problems. For the StackOverflow problem "set -o nounset" can be a good safeguard. Other options to look into to safeguard bash scripts from some insane behavior are "errexit" and "pipefail". Even though setting these is good practice, it doesn't stop some stuff that could be expected to be stopped by these. These options are not inherited to subshells invoked by command substitution and the likes. They wouldn't have stopped this nasty steam bug [1] for example. There are other nasty quirks too, it's really hard to unfck bash.
[1] https://github.com/ValveSoftware/steam-for-linux/issues/3671...
I quit using bash for scripting a few months ago. Now I use haskell with shell-conduit: http://chrisdone.com/posts/shell-conduit and bash only for very very simple things where haskell would be just overkill.
I've briefly looked at rc, but while it's significantly simpler and more orthogonal than sh it's got it's own weirdnesses; but the 'Design Principles' section here is worth reading: http://plan9.bell-labs.com/sys/doc/rc.html
Surely there must be a usable shell wrapped around an actual modern language?
Also, a nice experiment: http://xonsh.org/ (Bash-alike with embedded Python)
It has two modes, which can be a bit confusing. A python mode and a bash-ish mode.
testdata = $(ls -l) #Takes thes bash command 'ls -l' and saves it to the python variable testdata
echo ${testdata.upper()} | grep XLIO
$(ls).split("\n")
Yes, PowerShell. And it may actually arrive at Linux/Unix soon, due to CoreCLR. The specification is already open, but until now not much progress has been made towards bringing it uncrippled to Linux/Unix
PowerShell is extremely consistent. Examples: All commands are strictly on the verb-noun form where there are only 40 or so "approved" verbs. Noun represent the topic, so if you are working with ACLs, the commands are Get-Acl, Set-Acl, and if you are working with network network adapters, the commands are Disable-NetAdapter, Enable-NetAdapter, Get-NetAdapter, Rename-NetAdapter, Restart-NetAdapter, Set-NetAdapter. All (PowerShell) commands require the parameters in the same way (no - and -- confusion) as it is actually the shell that does the parameter parsing.
The grammar is "modern" so it has no surprises for anyone used to context-free grammars (like C, Python, Java, ...).
PowerShell is certainly flexible as it comes with the ability to invoke anything that has an exposed .NET API, or even has a WBEN/CIM standard interface (like some network switches etc).
AFAIK, the answer is no. I've spent a bit of time thinking about this problem and my conclusion is that the things that make a shell nice to use interactively are the same things that make it bad as a programming language. Rc may be as close as we will ever get to it.
I'm curious as to why you say that? This is a naive question, i have no skin in the game.
There is just one thing I will never understand. The tired argument of "...but it isn't portable". Features that are new, and make programming bash easier (such as "[" vs "[["), are looked down upon in some circles because it isn't portable. If I'm programming for bash, then upon deployment, I'll be using bash. To use another shell, and hope it just works is a bit insane.
I'd also like to second using the Fish shell. Far better than bash/zsh for everyday use, and I just can't go back to other shells.
I do know that all these problems result from fish having a saner syntax compared to bash (hell, FWIW I'm still mad that globs are not regular expressions and have a different syntax) but everytime someone points out these problems the reaction is "#!/bin/bash", which kinda misses the point.
Unless you're on Ubuntu, in which case you will be using /bin/dash at occasionally entirely unexpected moments.
That's why I only learn Bash. One lesson for everything for both purposes ;)
And system administrators should use Ruby if given a choice.
My #Bash" history has > 96k entries (woh, believe it or not; because of this too big number, "xterm" + "screen" always stuck when exitting; but "urxvt" + "tmux" work perfectly thanks to "urxvt" daemon mode.)
Porting this huge history database from my daily "bash" to "fish" is just a nightmare ... :D
This is doubly true if you have to chain together external scripts - the "easy" ways to do it in Python can have some very major limitations.
I liken Bash scripting to Perl scripting. You can write safe, beautiful, and readable code in both. However, you can also create a summoning circle to the 5th circle of hell if you don't spend the effort to make it safe, beautiful and readable.
You are correct that the main weakness of ipython is that it doesn't have pipes, and that chaining is very limited. But usually this does not impact me. And if all your scripting is in python, then you just import functions and run them, rather than chaining scripts together.
Bash is a shell, but Bash is not the shell!
If you don't know how to use your shell, block yourself off an evening with this book and change how you forever use you computer.
That's because '[[' is a special bash extension which started out as a better '[' which is actually a binary (/usr/bin/[). And, well, you have to have a space between an executable and its first argument.
(nowadays '[' and '[[' are builtins in most shells, but the external binary still exists).
- `[` is treated as a statement
- `[[` is treated as an expression
Which, for example, is why you can't use `>` in `[` based expressions. Bash thinks you want to redirect the output of `[` to somewhere else. This restriction is lifted for `[[` and makes for much more natural looking code.
Bash/sh is a horrible programming language.
I write my scripts in PHP if they're moderately complex, and only use Bash for dumb lists of commands.
My current project has a lot of bash. The program itself is just `foo | bar | baz | ...`, but the associated test script has grown quite long.
I've just added an extra test which calls shellcheck on each script, and it's spotted a bunch of redundant code for me :)