7 ms·

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/202

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 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 pipeline of three commands, with actual error handling, is probably more code in bash than in any other language.

pizza234 4y ago
> 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 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).
- thomashabets2 4y ago
  > "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.

pizza234 4y ago

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

thomashabets2 4y ago
> "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.