Earlier quoted context omitted.
I moved over to shellharden a while ago. It can actually apply the suggestions it makes. Aside from that, my employer is somewhat disapproving for GPLv3 tools, but MPL that shellharden uses is essentially auto-approved. https://github.com/anordal/shellharden
> my employer is somewhat disapproving for GPLv3 tools Let's hope it's not bash scripts you're writing :-) http://git.savannah.gnu.org/cgit/bash.git/tree/COPYING
Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
101–110 of 114 posts
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#102Earlier quoted context omitted.
I moved over to shellharden a while ago. It can actually apply the suggestions it makes. Aside from that, my employer is somewhat disapproving for GPLv3 tools, but MPL that shellharden uses is essentially auto-approved. https://github.com/anordal/shellharden
How is GPLv3 any different from MPL when it comes to use (as opposed to modification or distribution)?
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#103Earlier quoted context omitted.
The `let ++` example is pretty damning. I find Bash to be a poor and outdated shell that we’re stuck with for now. Its design is the best argument against LSD I know, it came out of the hippie drug days, and Bash reflects that with its madness.
A lot of the sins of shell are from it's primary role as an interactive interface to the computer. it's use as a scripting language was a nice secondary goal. On the one hand it is nice to have your interactive interface and your scripts be the same language. on the other it is a bit horrifying the way all those convenient interactive features make your programs so prone to failure.
I wouldn't mind it if all scripting in the shell had to be offloaded to a completely separate language that was less error prone and more consistent.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#104Because bash error handling is a thousand blades and no handle. https://blog.habets.se/2021/06/The-uselessness-of-bash.html I've reviewed a lot of code, bash and otherwise. I have never, not once, reviewed bash code that didn't have subtle bugs. And this is code written by smart people.
> Because bash is thousand blades and no handle. FTFY. It really is absolutely terrible tool as programming language. If your script is more than "a bunch of pipes in a trench coat" just use something else. I'd unironically prefer Perl to it.
"Real" programming languages usually have painful-to-use APIs for calling commmands, redirecting output, piping one command to another, etc.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#105and even then, shelling out from another language when absolutely necessary can be a better option
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#106Earlier quoted context omitted.
Never used OilShell (OSH) before, but this opening line on their home page struck me: > … and it's a new language for Python and JavaScript users who avoid shell! Why not work towards using python/JavaScript as shell languages? There was a HN thread a few days ago on Xonsh, the main python attempt at this which looks nice to me, which naturally got a lot of anti-anti-bash energy. But if we want better shell ergonomic…
> Why not work towards using python/JavaScript as shell languages? I always refer to this awesome answer to that question: https://stackoverflow.com/a/3640403/512904
> I have the feeling that trying to address these points by bolting features or DSLs onto a general-purpose programming language doesn't work. At least, I have yet to see a convincing implementation of it.
… and what is worth doing, a new shell or new features in an old language, which isn’t addressed by that post AFAICT.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#107The -e terminates the script at every failure not caught by a try...catch.
With this in mind, it's easier to predict bash's behavior.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#108Earlier quoted context omitted.
> Why not work towards using python/JavaScript as shell languages? I always refer to this awesome answer to that question: https://stackoverflow.com/a/3640403/512904
Nice run down. But in this context it seems to boil down to > I have the feeling that trying to address these points by bolting features or DSLs onto a general-purpose programming language doesn't work. At least, I have yet to see a convincing implementation of it. … and what is worth doing, a new shell or new features in an old language, which isn’t addressed by that post AFAICT.
https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell
https://github.com/oilshell/oil/wiki/Alternative-Shells
It doesn't mean they aren't useful, but we still need a better successor to Bourne shell / bash.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#109Earlier quoted context omitted.
The `let ++` example is pretty damning. I find Bash to be a poor and outdated shell that we’re stuck with for now. Its design is the best argument against LSD I know, it came out of the hippie drug days, and Bash reflects that with its madness.
> The `let ++` example is pretty damning. Seems kind of logical, the following c code behaves the same way. #include int test(void) { int i=0; return i++; } void main(void) { printf("i = %d\n", test()); } 'let i++' evaluates to / returns 0 before increasing i, just like c would.