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

161–170 of 258 posts

Re: Pure Bash Bible

#161

Post by dec0dedab0de »

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.

My rule of thumb is to use a real language if there is more than one if fi block.

Re: Pure Bash Bible

#162

Post by cauthon »

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

Agreed. My threshold is usually "when you want to start using arrays or dictionaries". I find bash best for file manipulation and running programs in other languages

Re: Pure Bash Bible

#163

Post by bokchoi »

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

This is so awesome. I need to play with this.

Re: Pure Bash Bible

#164

Post by tannhaeuser »

dyanaraps wrote: post #18
tannhaeuser wrote: post #9

Didn't realize at first that "pure" refers to features available in bash without calling out to external processes, when I would've thought purism in this context should refer to avoiding bashisms and writing portable (ksh, POSIX shell) scripts.

I understand your concerns about bash features and POSIX compatibility. The bash bible was written specifically to document the shell extensions bash implements. My focus for the past few months has been writing a Linux distribution (and its package manager/tooling) in POSIX sh. I've learned a lot of tricks and I'm very tempted to write a second "bible" with snippets that are supported in all POSIX shells. (I created…

I just wanted to add I'd be very interested in your shell-based package manager as well!

Re: Pure Bash Bible

#165

Post by joombaga »

zests wrote: post #137
mankyd wrote: post #128

Earlier quoted context omitted.

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.

Single square bracket conditionals [] are the "older" (POSIX) version but do not have certain features that we would like to use in our shell scripts. Bash uses double square brackets to extend the functionality. This is my understanding. Possibly not 100% correct but essentially correct enough for me to understand the reason/rationale for the difference.

You got it! `test` is a shell builtin. `[` is basically syntactic sugar, and is a synonym for `test` with the additional requirement that the last argument must be a closing bracket `]`. `[[` is a shell keyword with more features.

Re: Pure Bash Bible

#166

Post by joombaga »

cblades wrote: post #145
serhart wrote: post #139

Earlier quoted context omitted.

I'm in no way defending bash as a language. There are lots of gotchas and weird constructs. I avoid bash too. It's just that trim function isn't that cryptic or "unreadable" if you know the syntax.

Maybe "unreadable" and "readable" aren't the best ways to approach this conversation. It's certainly less readable than, say, my_str.strip()

Are you comparing a call to a definition? `trim_string "$my_str"` is no less readable than `my_str.strip()`.

Re: Pure Bash Bible

#167

Post by hnlmorg »

jigglesniggle wrote: post #142
hnlmorg wrote: post #89

Earlier quoted context omitted.

If you pardon the shameless self promotion; I'm working on something just like that: https://github.com/lmorg/murex It currently has: * Proper error handling (eg try and catch blocks) * unit testing and debugging frameworks to help with development and maintainability * data-type aware, including complex types like how CSV, JSON and YAML are all handled as memory structures and thus the same tools can query any struc…

Nice project, look forward to seeing a HN post on it!

Thank you

Re: Pure Bash Bible

#168

Post by kamaal »

masklinn wrote: post #61
kamaal wrote: post #58

Earlier quoted context omitted.

That's not as easy as cat something | grep "this" | cut -f 1 | sed -e 's/.../.../' You end up writing too much code, it's very verbose. Some times symbols are what you want. In fact the biggest progress in the growth of Math happened when they tossed out doing math with words and bought in symbols.

> That's not as easy as > cat something | grep "this" | cut -f 1 | sed -e 's/.../.../' Literally none of this is actually useful if you're already in Python: ( line.split('\t')[0].replace(…, …) for line in open('something') if 'this' in line ) > You end up writing too much code I can believe that if you're calling to external processes to perform operations which are pretty much trivial in the language.

Of course, if you plan to use one $language alone, you can do anything in that $language.

This question is specific to pipes.

Re: Pure Bash Bible

#169

Post by Koshkin »

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

It might be worth it to learn it though, even if just for fun.

Re: Pure Bash Bible

#170

Post by deschutes »

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

The human part is a hyperbole. "This code is unreadable" implies "This code is unreadable for the intended audience."

Here's how I'd write that function: trim_string() { python3 -c 'import sys; sys.stdout.write(sys.argv[1].strip())' "$1" }

Post reply on HN