4 ms·
Interesting stuff, but given bash's - Relative unportability - Poor noncompliant sh interpreter - Poor performance (can be 4x slower than POSIX sh shells like
by Aelius 8y ago
Interesting stuff, but given bash's
- Relative unportability
- Poor noncompliant sh interpreter
- Poor performance (can be 4x slower than POSIX sh shells like dash for certain tasks)
I personally think bash is always the wrong choice. Use POSIX sh (or a real language). POSIX sh is 98% the same thing, there's no good reason to even use bash over sh in the vast majority of cases. It's just this blight that won't go away.
Given that bash is mostly sh anyway, most of this writeup applies to sh, too. AFAIK the only thing bash-specific here is arrays.
- raggi 8y ago[[ alone is reason enough to prefer bash over sh on teams where you inevitably have non-experts making changes. Safe Bash is hard to teach, posix is far harder.
- rascul 8y agoI stick with bash to avoid implementation differences due to POSIX ambiguity [0]. I know that all my bash scripts will run on at least bash-4.0 but I have no idea what shell /bin/sh is going to be for any given system. I haven't written a single shell script where the performance difference matters, nor do I expect to. And there are a few nice bashisms besides arrays. I'm not sure what portability issues you're referring to. [0] https://stackoverflow.com/a/16376043 https://stackoverflow.com/a/16376043
- frou_dh 8y agoI agree with you, but there's one fly in the ointment. POSIX Shell does not support local variables! Writing functions without being able to have local variables? That's pretty damn gross. So I use the `local` keyword, and now my scripts aren't strictly POSIX Shell any more.