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

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

#111

Post by HdS84 » Sun, Oct 09, 2022, 6:22 PM UTC

justin_oaks wrote: post #104

xani_ wrote: post #71

Earlier quoted context omitted.

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

Powershell core. It's actually usable and allows to use .net tools if you need to break out the big guns. Main drawback is the stupid channel thing, but that's manageable.

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

#112

Post by draegtun » Mon, Oct 10, 2022, 3:41 PM UTC

justin_oaks wrote: post #104

xani_ wrote: post #71

Earlier quoted context omitted.

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

Tcl would be a good choice here - https://www.tcl.tk/man/tcl8.5/tutorial/Tcl26.html

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

#113

Post by pizza234 » Tue, Oct 18, 2022, 10:24 AM UTC

thomashabets2 wrote: post #70

pizza234 wrote: post #59

Shell scripts can be thought like C++. They can be sanely managed only if one adopts a strict subset of functionalities. The page is probably oriented at situations where one needs to support any version of bash and any obscure/inadvisable functionality (mind that there are still devs that mix sh and bash syntax in the same script), which is very inconvenient and error prone, so manual error handling may make sense.…

I disagree. Bash basically cannot be used correctly. It's like gets() in C; a knife with a blade but no handle. Unsafe at any speed. https://blog.habets.se/2021/06/The-uselessness-of-bash.html C++ can be used correctly. It's easier since C++11, with smart pointers and stuff. I'm not going to argue that writing solid C++ is easy, but it IS possible. Bash basically can't be used correctly. Even a simple command pipelin…

> I disagree. Bash basically cannot be used correctly. It's like gets() in C; a knife with a blade but no handle. Unsafe at any speed.

> C++ can be used correctly. It's easier since C++11, with smart pointers and stuff. I'm not going to argue that writing solid C++ is easy, but it IS possible.

It seems this conflates two different aspects of programming languages - complexity and (memory) safety.

The analogy with Bash was in relation to the language complexity. By reducing the language features to a restricted, well-known (by the given team) scope, it's possible to use the language effectively. A very good example of this is the Doom 3 source code.

In relation to memory safety, Google hasn't been able to develop a safe enough Bluetooth stack, which has been a dumpster fire. Due to the small support windows of Android, as of today, a huge amount of devices with older Android versions are either in the garbage, or are extremely unsafe. If Google, with their engineering practices, can't develop a safe Bluetooth stack in an unsafe language, realistically, nobody can.

> https://blog.habets.se/2021/06/The-uselessness-of-bash.html

The topic in the post is very interesting (pipes error handling are no doubt a rough area of Bash), but the post takes the choice of being a rant rather than an informative research. The central thesis that "functionality of language X is broken in a 1-line program, but it works in a 83-lines program in language Y" doesn't have any meaningful conclusions. It would have been interesting and informative to compare against the correct version in language X, which in the case of Bash, it does exist (but in this case, it's advanced Bash, and sure, it's ugly).

There is a very wide gap been 1-, 10-, 100- and 1000- line programs, and very different requirements. Asserting that only the 1-line case is the only valid use case for shell scripting, it's inefficient system administration (assuming disciplined shell scripting).

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

#114

Post by thomashabets2 » Tue, Oct 18, 2022, 5:20 PM UTC

pizza234 wrote: post #113

thomashabets2 wrote: post #70

Earlier quoted context omitted.

I disagree. Bash basically cannot be used correctly. It's like gets() in C; a knife with a blade but no handle. Unsafe at any speed. https://blog.habets.se/2021/06/The-uselessness-of-bash.html C++ can be used correctly. It's easier since C++11, with smart pointers and stuff. I'm not going to argue that writing solid C++ is easy, but it IS possible. Bash basically can't be used correctly. Even a simple command pipelin…

> I disagree. Bash basically cannot be used correctly. It's like gets() in C; a knife with a blade but no handle. Unsafe at any speed. > C++ can be used correctly. It's easier since C++11, with smart pointers and stuff. I'm not going to argue that writing solid C++ is easy, but it IS possible. It seems this conflates two different aspects of programming languages - complexity and (memory) safety. The analogy with Bas…

> "functionality of language X is broken in a 1-line program, but it works in a 83-lines program in language Y"

Fair criticism. The difference though being that bash is implying a promise of being able to provide a solution in one line, but if you actually try to make bug free programs it'll end up being just as long as in Go. Without the readability, since you have to jump through crazy amounts of hoops since even the fixes/workarounds for the problems in bash don't have support in the language.

This makes bash's supposed strengths actually weaknesses, even for small programs.

> (pipes error handling are no doubt a rough area of Bash)

But that's my point when I condense this to calling bash useless. Pipes are maybe the core way that one ties together components in bash, and error handling is very important to not have bugs. Unhandled or mishandled errors are bugs.

> Asserting that only the 1-line case is the only valid use case for shell scripting

Well, I'd say that a 1-line case will not be correct, but will work in most day to day, if supervised.

And a correct shellscript can never be 1 line, and making it correct would make it 10s or 100s of lines of unreadable mess, that nobody would actually write or maintain.

Maybe there are wizards out there who write bug free bash. I've never met one. I've met many who think they are.

Most would probably be surprised that they'd have to write at least tens of lines of code to replace their use of the pipe operator, to have bug free code.