Hacker News Reader

Comment by haolez | Hacker News Reader

I love Bash as a language. I'm part of a very small crowd :)

I’m a very big bash scripter - to the disdain of many younger colleagues. They prefer golang, typescript, node. I find it hard to relate. I write bash scripts to automate batch commands I find myself running as part of my job. I like the terminal and posix utilities. Very flexible and easy to read, to me.

Can I have a look at them?

Does your script parse arguments and provide good documentation with -h of what can be done with it but if needed?

Odd question. Those are not the kinds of things that are difficult to do in shell scripts.

I find that Golang is an especially good companion for Bash, because it is quite easy to write and deploy your own CLI tools for task which have higher performance requirements.

Well, it certainly has some strong parts, but there are some parts which are so horribly broken, that the good parts can't keep up.

Just to give one example: The topic of errexit aka `set -e`.

In the beginning, I thought it should be an easy decision and since programs are supposed to be reliable, they should terminate in case of an error. So I added `set -e` to all my scripts. However, later I learned, that if you call a function from within a condition, the function is executed without `set -e` even if the function itself sets the option. Since then, I am unsure if it is better to have a function that 'sometimes exits' when it comes across an error or 'never exists' when it comes across an error, because 'always exists' when it comes across an error does not exist.

Could one really on "always" when SIGKILL can make programs simply disappear?

I'm preparing to release bash-modules 4.0 [0]. Can you give me feedback, please? I'm a non-native English speaker, so I need someone to help fix spelling mistakes, at least.

[0]: https://github.com/vlisivka/bash-modules

You might want to check out one of my projects called: module.sh [1].

It is still a work-in-progress project and the documentation on the website is not up-to-date, but I think we are working on the same problem ;-)

If you want to run probably all the code I have written, you can run the test-suite like:

  curl -fsL https://mdl.sh/development/tools/run-all-tests/run-all-tests-0.9.16.sh | sh

A total run-time of 8 Minutes is normal and there is little output in the beginning.

The code is available on Github[2].

[1]: https://module.sh

[2]: https://github.com/arendtio/mdl.sh

IMHO, you should use unofficial strict mode (set -ueEo pipefail; trap "Error at ..." ERR ) often, because it catches a lot of bugs. Sadly, strict mode doesn't work in subshell.

Also, code without comments and documentation is useless, because developer must invest some time into browsing and understanding of your code first, but, often, it faster to rewrite code from scratch instead.

Also, you forget to include a license for your code, so nobody can use your code for any purpose.

I like the idea of downloading of modules at demand, with verification of integrity. I'm looking to implement something like that for my project too, but I'm afraid that I will not be able to implement it securely enough.

One difference between the projects is that you are targeting Bash and I am targeting POSIX. Therefore, using the 'unofficial strict mode' is not an option for me. However, good tests can compensate a lot and are necessary anyway.

Yes, there are certainly some modules which lack comments. On the other hand, there is at least one module which has its own readme to explain the code:

https://github.com/arendtio/mdl.sh/tree/master/development/d...

Regarding the security: As said, I am targeting POSIX and as far as I know, the only checksum tool available is cksum. This is borderline insecure but catches transmission errors at least. However, if you do not have such strict requirements you can easily use something like sha256sum. In fact, my module allows to use alternative checksum tools but uses cksum if nothing else is specified (because it is better than nothing and always available).

Larger than you'd think. Lots of people like to make a rich bashrc. Functions in a bashrc are amazing.

And lots of people use Nix - and write a lot of bash.

Can you point to examples, please? `bash` is hard to write properly.

It is hard to write properly, but most use is hacky. It works for the intended purpose. ShellCheck does go a long way tho.

I love Bash too, but using it daily is probably more inertia than anything else. Some things are just downright horrible (for the life of me, I can never remember associative array syntax off the top of my head) but it's just so good when it comes to other things that it's worth sticking to.

Reply on news.ycombinator.com