Live data from Hacker News

Pure Bash Bible

github.com

121–130 of 258 posts

Re: Pure Bash Bible

#121
post #38

While this is interesting I see doing anything but launching programs with simple text-substituted arguments as too much for bash or sh. Run shellcheck on some of your own code, or the code of even a simple project to see how hard it is to really use bash. Why I think people gravitate towards it is because languages such as python add too much pomp to launching a shell process. A language like perl is usually easier…

Yes, Python is the Cobol of script languages.

What? Why?

Re: Pure Bash Bible

#122

I have a personal dislike for regexes and non human readable code, it gives maintenance headache. It's why I avoid shell scripts as much as possible. The first example is not human readable, if the name of the function is a lie, I have no idea what this piece of code do : trim_string() { : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" }

Just because you seem to be unfamiliar with bash doesn’t mean it’s unreadable. Almost any language will look cryptic if you don’t know it. That function is mostly just parameter expansion and very common in most bash scripts. I bet if you read the manual you would easily be able to figure it out. You just have to learn the language.

Re: Pure Bash Bible

#123

Hello, I'm the author of the Pure Bash Bible. Happy to answer any questions you may have. Here's an example of what bash is capable of: https://github.com/dylanaraps/fff/ (a TUI file manager written in bash)!

fff looks amazing. I’ve started building something like it many times, but never finished. Thank you

Re: Pure Bash Bible

#124

Earlier quoted context omitted.

I'll look into also putting the book on Amazon or another "ebook" website. I chose leanpub as it _is_ for books like this but if it does cause issues for people I'll explore my options on other platforms. Thanks for letting me know and apologies for the inconvenience.

It's more an annoyance than really a problem and stick with them rather than Amazon. Leanpub looks like a nice enough bunch and you, as the author, receive most of the proceeds. I'm probably anyway the exception nowadays not being able to access private email remotely. But what you may point out to them is that it may be worthwhile to think through their checkout process. Also for their own benefit and the benefit of…

I'm a bit puzzled how you've ended up with a system where you can't access email remotely. That probably took a lot more time than just creating a gmail account or even using your own domain but hooking it up to google for all the boring stuff (like, uh, making it available remotely). Although you mention "private" email so perhaps you also have "public" email which you can access - i'm not sure how I'd configure mail servers to deal with that. Back when I wasn't confident accessing email via random internet cafes etc from my phone I created several accounts and have stuck to that system; some accounts i only access when i'm sure it's safe, and others - not used for banking etc - i couldn't care less about and use from anywhere.

Re: Pure Bash Bible

#126

I have a personal dislike for regexes and non human readable code, it gives maintenance headache. It's why I avoid shell scripts as much as possible. The first example is not human readable, if the name of the function is a lie, I have no idea what this piece of code do : trim_string() { : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" }

I have a personal dislike for "non human readable" used as shorthand for "not immediately and easily readable by me".

Re: Pure Bash Bible

#127

I have inherited about 4K LOC Bash, which mostly works as advertised. No one wants to touch it! suggestions ?

Leave it alone if you don't need to modify it. If you start needing to modify it a lot start rewriting it in ruby, go, or python at that point. Use set -x at the top of the file to get an idea on what's going on.

Re: Pure Bash Bible

#128

I have a personal dislike for regexes and non human readable code, it gives maintenance headache. It's why I avoid shell scripts as much as possible. The first example is not human readable, if the name of the function is a lie, I have no idea what this piece of code do : trim_string() { : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" }

Just because you seem to be unfamiliar with bash doesn’t mean it’s unreadable. Almost any language will look cryptic if you don’t know it. That function is mostly just parameter expansion and very common in most bash scripts. I bet if you read the manual you would easily be able to figure it out. You just have to learn the language.

I'm with jmnicolas on this. I've been using bash on and off for years now (approaching decades). I still get it very wrong almost always. It's the only language where this is a persistent problem for me.

Just yesterday I was struck by the difference between if [[ ]]; and if [ ];

I didn't even bother grokking the difference in the end. I simply found something that worked and moved on with my day.

Re: Pure Bash Bible

#129

I have inherited about 4K LOC Bash, which mostly works as advertised. No one wants to touch it! suggestions ?

Assuming it's all in one file I would move related pieces of functionality into separate files and and then source them when necessary. Should make things more manageable for people only wanting to make small changes.

Re: Pure Bash Bible

#130

I have a personal dislike for regexes and non human readable code, it gives maintenance headache. It's why I avoid shell scripts as much as possible. The first example is not human readable, if the name of the function is a lie, I have no idea what this piece of code do : trim_string() { : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" }

Just because you seem to be unfamiliar with bash doesn’t mean it’s unreadable. Almost any language will look cryptic if you don’t know it. That function is mostly just parameter expansion and very common in most bash scripts. I bet if you read the manual you would easily be able to figure it out. You just have to learn the language.

My disclaimer is that I love bash. I write way too many things in bash. But eventually I go back and refactor the scripts into Python (or lately, Go) because I am so sick of people refusing to touch my bash scripts.

String munging in Python is so much objectively easier to read than bash. I would say that it's because it is similar to a lot of the more popular languages than the sort of cryptic parameter substitution bash provides. And if that makes it easier to maintain some automation, then its worth the effort just to use Python IMO.

Post reply on HN