"Superior strength" is probably just a matter taste, however I would really like to read your explanation on why you think so.
Some reasons why POSIX shells are great:
- they are part of POSIX (a Standard which is implemented by multiple OS) and therefore often available
- you can use them to compose programs written in different languages
- you can easily connect the output of one program with the input of another (pipes)
> they are part of POSIX (a Standard which is implemented by multiple OS) and therefore often available
That's not an intrinsic property of Bash.
> - you can use them to compose programs written in different languages
> - you can easily connect the output of one program with the input of another (pipes)
This last point subsumes the previous one. So basically, you're saying Bash is great because it's a shell?
myFunc() { (
#...
) }
So in this case I don't think it makes sense to make a distinction between the two. In essence, I think Bash and the other POSIX shells share most of their greatest strengths and weaknesses.1. Return values of subshells 2. Clean design 3. being a "real" programming language
The only Bash specific part was
> You should stop using Bashisms and subtle, obscure language features unless you absolutely have to.
But in fact, the usage of subshells to limit the scope and subshell return values have nothing to do with Bashisms.
Edit: It seems I should elaborate.
> Getting anything out of a subshell that isn't from STDOUT is impossible. So you can't define an array in a subshell and then use it outside the subshell, and you can't return an array (or anything that isn't a string) from a subshell. If you only use subshells and want to use any kind of data structure that isn't a string passed from STDOUT, you have to do it globally.
Yes, but that is no problem at all, because that is the way shell scripts work and if you do it in a functional way, where the function has no state, it is great (we a few exceptions).
> And subshells are slow. So nobody uses subshells.
Shell scripts are slow in general, subshells don't make an exception but also don't have a large impact. And people do use subshells.
> If you use Bash for programming, you have to stop thinking in terms of the holier-than-thou software engineer, whose ego believes that a superior, "clean" design makes a superior program. You should embrace globals. You should switch between using or not using the enforcement of set variables or program exit status. You should stop using Bashisms and subtle, obscure language features unless you absolutely have to.
If you use Shell scripts, you should understand that this language has been designed decades ago and that professionals advise to use it just in short scripts to connect binaries.
> Bash is not a "real" programming language, so do not treat it as one. Do not look for hidden features, or try to do things in cute ways that nobody else uses. There is no superior method or hidden knowledge. Just write extremely simple code and understand the quirks of the shell.
That part is mostly okay, but "real" doesn't get the point, as it is a real language, just one with many problems. However, given its superior strength we haven't overcome it yet...