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

191–200 of 258 posts

Re: Pure Bash Bible

#191

Post by inimino »

deschutes wrote: post #170
inimino wrote: post #126

Earlier quoted context omitted.

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

The problem is the direct logical implication of the hyperbolic statement "X is not human-readable" is that only non-humans can read X. Which is rude.

Re: Pure Bash Bible

#192

Post by papito »

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.

I don't think it's a matter of familiarity. Most of us here have used multiple languages, and I have no problem saying that the Bash syntax is atrocious.

"How do we close a statement.... errr. Let's spell it backwards".

Re: Pure Bash Bible

#193

Post by imihai1988 »

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

those are not regexes though, are they ? apart from the [:space:] part

Re: Pure Bash Bible

#194

Post by munk-a »

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 think this bible is an interesting attempt at avoiding call outs but... I agree with the parent - /\s(.?)\s/\1/ is just easier to read, even with character classes /[:space:](.?)[:space:]/\1/ than the trim example, it's actually a bit sad that string manipulation is the first section since string manipulation is such an inherently dirty task to do.

It is neat to discover functionality of bash I was unaware of by see folks push it to the limit though.

Re: Pure Bash Bible

#195

Post by munk-a »

ulysses wrote: post #181
deschutes wrote: post #170

Earlier quoted context omitted.

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

"A collection of pure bash alternatives to external processes."

It is a neat academic exercise to find these but I think that's sort of the point - why?

If you're building something that multiple folks will be reading and using just call out to external processes and make it easier to follow what's going on. It's neat to know how to do these things, but they're honestly a bit of a security hole because a large portion of folks using them will never comprehend the why and how and just assume it's doing the proper what.

Re: Pure Bash Bible

#196

Post by throwaway_se099 »

papito wrote: post #192
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 don't think it's a matter of familiarity. Most of us here have used multiple languages, and I have no problem saying that the Bash syntax is atrocious. "How do we close a statement.... errr. Let's spell it backwards".

> "How do we close a statement.... errr. Let's spell it backwards".

That's on the original Bourne shell and its author's evident love for Algol 68. Wikipedia has a fine summary.

Re: Pure Bash Bible

#197

Post by Jenz »

IronWolve wrote: post #186
rhizome31 wrote: post #102

Earlier quoted context omitted.

Not defending this particular example, but there are contexts where avoiding an external call can make a difference. Think a script calling an external program in a deeply nested loop. This sort of optimization could be used as a last resort, after identifying a real performance issue and evaluating the possibility of restructuring the code.

I've ran into this decades ago with file servers back. Half a million files, takes too long to do a simple for loop and calling 3rd party processes for awk/sed when I was just using them to format/search text. Breaking it down to just to mosty bash one scripts reduced the run time and ended all pauses.

I was going to argue that it would be better to simply not use a shell for that, but

> decades ago

Frankly, I can only imagine how the environment then would be. Thinking back with your current experience, what do you think you would have done if you had to fix it again?

Re: Pure Bash Bible

#198

Post by Jenz »

rhizome31 wrote: post #100
Jenz wrote: post #99

Earlier quoted context omitted.

I was talking about the implementation. To whoever has implemented and who will maintain this; to them I think this will read horrible, and that is not good even if it is invisible to an end-user. I mean, how long wouldn’t even a very experienced bash programmer take to understand that substitution...

To be fair this is one of the least readable examples of the document. They're not all that bad.

Yes, far from it. Actually a lot them seem very intuitive, esp.

  lower() {
      # Usage: lower "string"
      printf '%s\n' "${1,,}"
  }
And with uppercase, "${1^^}" instead.

Re: Pure Bash Bible

#199

Post by yahnu »

hnarn wrote: post #67
dyanaraps wrote: post #15

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

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.

The site[1] where the video is actually hosted has the image you described as the avatar of the uploader. Could it be the reason?

1. https://asciinema.org/a/qvNlrFrGB3xKZXb6GkremjZNp

Re: Pure Bash Bible

#200

Post by ofrzeta »

lizmat wrote: post #178
fhood wrote: post #175

Earlier quoted context omitted.

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

That's an argument for types. While it's more convenient to use a language without types it's more error prone. So I guess in the end strong typing wins.

  >>> 0 + 42
  42
  >>> "0" + "42"
  '042'
  >>> "0" + 42
  Traceback (most recent call last):
    File "", line 1, in 
  TypeError: cannot concatenate 'str' and 'int' objects
  >>> int("0") + 42
  42
Post reply on HN