Live data from Hacker News

Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

mywiki.wooledge.org

101–110 of 114 posts

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#101
post #80

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

Yeah, other shell flavors are fine.

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#102

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

How is GPLv3 any different from MPL when it comes to use (as opposed to modification or distribution)?

I can only guess about the distinction our legal department sees.

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#103
post #12

Earlier 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.

We'd probably all be better off if our scripts weren't in the same language as used by our interactive interface. I do paste snippets of scripting (if, for, etc.) into my interactive terminal from time to time, but that's rare compared to just typing commands to run.

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)

#104
post #71

Because 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.

Is there any good alternative to bash for stringing together multiple commands with pipes and redirections?

"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)

#105
mountain out of a molehill imo. there’s a certain point where you’ll be fighting shell more than it’s helping—choosing another language is the better choice. i’m not a wizard but i feel like i’ve developed a decent intuition for what’s sane to do in shell and what needs something else.

and 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)

#106
post #37

Earlier 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

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.

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#108
post #106

Earlier 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.

A short answer would be that dozens of projects like this already exist and have existed for decades (scsh was mentioned in this thread), and they aren't widely used as shell replacements:

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)

#109

Earlier 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.

I don't mean what it returns, I mean that returning non-zero trips up Bash into thinking it's a non-successful error code. The fact that doing math can trip up error detection implies a fundamental design flaw of the system. Which, I mean, we're in Bash, of course it's poorly designed. I didn't know it was quite this bad though.
Post reply on HN