4 ms·
throwaway984393 <-- just a troll... Edit: It seems I should elaborate. > Getting anything out of a subshell that isn't from STDOUT is impossible. So you can't
by arendtio 5y ago
throwaway984393 <-- just a troll...
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...
- fstrthnscnd 5y ago> However, given its superior strength we haven't overcome it yet... "Superior strength" is probably just a matter taste, however I would really like to read your explanation on why you think so.
- arendtio 5y agoWell, if it would be just bad, why do we still use it? Why don't we use e.g. Python (which is a much better designed programming language)? 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)
- fstrthnscnd 5y agoso it's not Bash by itself which is great, it's POSIX shells? > 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?
- arendtio 5y agoBasically, yes. Most arguments expressed here apply to Bash as well as to other POSIX compatible shells. Even the trick from the initial blog post is also works for POSIX shell AFAIK (didn't check). Definitely working is something like (which is just a little more verbose): 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.
- fstrthnscnd 5y agoBut, wasn't the original argument discussing the merits of Bash as a shell? So you're saying that Bash is great as a shell because it's a shell?
- arendtio 5y agoMy understanding was, that the initial argument was about Bash as a programming language and most aspects discussed were aspects were Bash is no different than POSIX: 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.