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

141–150 of 258 posts

Re: Pure Bash Bible

#141

Post by jigglesniggle »

al_form2000 wrote: post #82
jigglesniggle wrote: post #21

Earlier quoted context omitted.

I think you're reading my comment the wrong way: I meant to say that doing e.g. piping in Python is a lot of pointless work (pomp), as you agree. This is perhaps one big benefit but not one that is exclusive to a sh-like language. Instead I would like to see a language with strong flow control or metaprogramming capabilities take on processes as a first class citizen. Perl is probably the closest but still has some w…

> Perl is probably the closest but still has some warts related to redirection. I wholehartedly agree on perl but can you expand on the redirection warts? I seldom had problems with perls' FHs, while, on the contrary I seem to be unable to wrap my head around the contorted syntax involved in bash's handling of descriptors - especially when more than 2 handles are involved.

Well -- I was comparing Perl to Python in this case. There is roughly the same amount of boilerplate and both are easier to read than bash's redirection.

The wart is that you need IPC::Open3 or equivalent because Perl's intrinsics can not synthesize the pipe operator (though you will think that they can) if you need to insert yourself into the middle of a chain of commands.

Nowadays there are decent wrappers for calling Open3 but more commonly you just find people running one half of the command, buffering the output, and passing it to the second half.

Re: Pure Bash Bible

#142

Post by jigglesniggle »

hnlmorg wrote: post #89
jigglesniggle wrote: post #21

Earlier quoted context omitted.

I think you're reading my comment the wrong way: I meant to say that doing e.g. piping in Python is a lot of pointless work (pomp), as you agree. This is perhaps one big benefit but not one that is exclusive to a sh-like language. Instead I would like to see a language with strong flow control or metaprogramming capabilities take on processes as a first class citizen. Perl is probably the closest but still has some w…

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!

Re: Pure Bash Bible

#143

Post by jigglesniggle »

mankyd wrote: post #128
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.

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.

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.

Re: Pure Bash Bible

#144

Post by serhart »

pretendscholar wrote: post #140
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.

I think the point is that it takes a lot longer pick the syntax up compared to some if/then/for/loop version of trim even if that would be way more verbose.

Yes, but I think that's antithetical to what languages like bash and perl are trying to do. Someone well versed in the language can do some pretty complex operations in a few keystrokes.

Re: Pure Bash Bible

#145

Post by cblades »

serhart wrote: post #139
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.

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()

Re: Pure Bash Bible

#146

Post by moviuro »

jbrnh wrote: post #81
YawningAngel wrote: post #77

Earlier quoted context omitted.

'System bash' isn't a universal or clear concept. For example, if you're using Modern OS X, you likely have bash via brew or some other userspace package manager but no system bash. Presumably you (or at least, most people) would still like your scripts to run in this case.

But if I write the script for a bunch of RHEL servers then OS X and brew are irrelevant, and the full path is better (IMHO). It's the 'always use env..' I object to.

It's RHEL... today. `/usr/bin/env` is a POSIX standard. Maybe one day, RHEL will put bash in /usr/local/bin. Or maybe you'll switch to FreeBSD one day, and suddenly everything goes boom.

Re: Pure Bash Bible

#147

Post by tckmn »

dyanaraps wrote: post #93
hnarn wrote: 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.

Telegram also shows my old Github avatar - it seems to cache them extremely aggressively.

Re: Pure Bash Bible

#148

Post by serhart »

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()

Sure, but bash only has certain language constructs. This implementation is using parameter expansion and some other built ins. It's definitely more complex than yours, but that's what bash has to offer.

Re: Pure Bash Bible

#149

Post by mankyd »

jigglesniggle wrote: post #143
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.

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.

Re: Pure Bash Bible

#150

Post by chapium »

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

Perhaps it shouldnt be defined as what the regex can do, but which unit tests its able to pass.
Post reply on HN