Live data from Hacker News

Pure Bash Bible

github.com

151–160 of 258 posts

Re: Pure Bash Bible

#151

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' "$_" }

[deleted]

Re: Pure Bash Bible

#152
post #149

Earlier quoted context omitted.

I highly recommend running shellcheck on all of your bash code. It is what finally taught me the practical difference between [[ and [. There are some tests that will always pass in [, for example, but work properly in [[; one project never realized.

My (personal) better recommendation is to avoid bash scripts whenever possible ;) I generally tell people that, once a script is longer than ~100 lines and/or you start adding functions, you're probably better off with something like Python. I know that's not a popular opinion with shell enthusiasts, but it's saved me so much frustration both in writing new scripts and coming back to them later for refactoring.

I agree, but I like phrasing it as "only run commands with substituted arguments." There's some more discussion on this below. :)

In the past I almost exclusively used Python, but I'm starting to like Go.

Re: Pure Bash Bible

#153
As someone that writes bash scripts regularly for my job, one of the big struggles I've had is remembering what I or someone else wrote when I look back 6+ months later haha.

I had the same issue with reading other people's perl as well.

I think the great and terrible thing about both languages is that there is literally a million different ways to skin the cat / write a regex.

Re: Pure Bash Bible

#154

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' "$_" }

> It's why I avoid shell scripts as much as possible.

This is all from somebody who has just written a linux user space. Perhaps the author avoids shell as much as possible. It just isn't possible. I doubt it, though. Bash is awesome.

Re: Pure Bash Bible

#155

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' "$_" }

Is the following a maintenance headache, or non-human readable?

  #!/bin/sh
  FOO=" some long string here "
  FOO="$( echo "$FOO" | sed -e ' s/^[[:space:]]//g; s/[[:space:]]$//g ' )"
This isn't "pure bash", but most of what I write in shell scripts isn't "pure bash". It's shell scripting: dirty, slow, easy, effective.

Like any 'language', it takes on the complexity you put into it. English is really complicated, but you can also use a subset of it with only 850, 1200, or 2400 words, and suddenly it's very simple and clear.

Re: Pure Bash Bible

#156
post #130

Earlier quoted context omitted.

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…

Python is a portability minefield. I'll spend more time trying to get the script/package run than reading the bash script.

Re: Pure Bash Bible

#157
This seems like a good time to mention my (ridiculous) project, a ctypes module for bash.

https://github.com/taviso/ctypes.sh/wiki

There are some little demos here:

https://github.com/taviso/ctypes.sh/tree/master/test

I even ported the GTK+3 Hello World to bash as a demo:

https://github.com/taviso/ctypes.sh/blob/master/test/gtk.sh

Re: Pure Bash Bible

#158
post #67

Earlier quoted context omitted.

This might be an odd/off-topic question, but in Telegram this article has an auto-fetched thumbnail of a cat smoking a cigarette and a text similar to 'heavy metal music playing', I'm just curious where this picture is from, if you have any idea? I checked the README for the repo, pictures of the contributors etc. but I'm unable to figure out where it's coming from.

That's a very very very old GitHub avatar of mine, I wonder why Telegram hasn't pulled a later one.

You can use https://telegram.me/webpagebot to refresh avatar cache

Re: Pure Bash Bible

#159
post #130

Earlier quoted context omitted.

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…

Python is a portability minefield. I'll spend more time trying to get the script/package run than reading the bash script.

Couldn't agree more, but honestly I think that is a completely overplayed issue. Just be explicit (This requires Python3.7) and have a requirements.txt file, maybe bundle with a `make install` command and move on.

If people can't figure that out... I don't know how you're going to expect them to read a cryptic bash script.

Don't get me wrong there is totally some good use cases for bash. Init-scripts come to mind when you don't want to lug around a Python VM in a lightweight container, for example.

Post reply on HN