Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pure Bash Bible

github.com

Post reply on HN
Print view View original

171–180 of 258 posts

Re: Pure Bash Bible

#171

Post by fhood »

inimino wrote: post #126
jmnicolas wrote: post #117

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

I'm not sure you are being fair. I think any frequent user of regex understands how easy it is to produce expressions that are very difficult to parse.

I also think that a discussion about readability makes sense in a post about Bash. I don't personally program very often in Lua, Go or Ruby, but for the most part when I encounter code in these languages I don't find it very difficult to understand and modify. In contrast to this, every encounter with a significant amount of Bash seems to lead to a great deal of googling.

Re: Pure Bash Bible

#172

Post by anaphor »

heuxbzjnz wrote: post #3

no mention of /dev/tcp?! yes, it looks like a device node in /dev, but it's really a pure bashism for opening tcp connections to arbitrary hosts and ports

https://www.linuxjournal.com/content/more-using-bashs-built-... has a decent explanation.

I came here to say the exact same thing. This is my favourite thing most people don't know exists in Bash.

Re: Pure Bash Bible

#173

Post by mistrial9 »

mistrial9 wrote: post #138
tjpnz wrote: post #129

Earlier quoted context omitted.

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.

no, its 27 directories and 947 files, with a plugin architecture (pipeline)

my mistake, the project is closer to 40,000 LOC, now that I count it...

Re: Pure Bash Bible

#174

Post by soheil »

jmnicolas wrote: post #117

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

Do you have a personal dislike for math too?

Re: Pure Bash Bible

#175

Post by fhood »

serhart wrote: post #122
jmnicolas wrote: post #117

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.

"Almost any language will look cryptic if you don’t know it."

Seems disingenuous to me. Java and Python are in a different class of readability than Bash or Perl.

Example: "abc" + "def" = "abcdef" vs "abc"."def" = "abcdef"

Re: Pure Bash Bible

#176

Post by Sir_Cmpwn »

Please limit your shell scripting to POSIX sh for the sake of broad compatibility with current and future operating systems. There's a quick reference here:

https://shellhaters.org/

If you find yourself frustrated by the lack of bash extensions, your program is probably complex enough that you probably shouldn't be writing a shell script.

Re: Pure Bash Bible

#177

Post by donpdonp »

taviso wrote: post #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

"ctypes.sh is a bash plugin that provides a foreign function interface directly in your shell."

Re: Pure Bash Bible

#178

Post by lizmat »

fhood wrote: post #175
serhart wrote: post #122

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.

"Almost any language will look cryptic if you don’t know it." Seems disingenuous to me. Java and Python are in a different class of readability than Bash or Perl. Example: "abc" + "def" = "abcdef" vs "abc"."def" = "abcdef"

> "abc" + "def" = "abcdef" vs "abc" . "def" = "abcdef"

Would be better comparison if you would use whitespace in the other case as well. Which then makes it just as readable.

Also. "0" + "42" would that be "042" or 42? It may be better readable, but the semantics are unclear.

Re: Pure Bash Bible

#179

Post by iandinwoodie »

Dylan, I was wondering if you could share your process for going from chapter text files to a full ebook? This looks like a really approachable way to writing a book. Is the conversion something scripted or is it a more involved process?

Re: Pure Bash Bible

#180

Post by shrimp_emoji »

mankyd wrote: post #149
jigglesniggle wrote: post #143

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'm so glad I'm not alone in this.

I never even bothered to learn Bash properly because even that's difficult, and I figured it'd be "good mental money after bad". And, now that Python ships with all distros, I feel even less need to.

I do like Bash's range syntax though:

    for i in {0..5} ; do echo $i ; done
Like Ruby's. It's so nice! D: I lament Python's lack of it.
Post reply on HN