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

61–70 of 258 posts

Re: Pure Bash Bible

#61

Post by masklinn »

kamaal wrote: post #58
masklinn wrote: post #47

Earlier quoted context omitted.

Don't see why it "doesn't scale well", the overhead is roughly constant: use the stdout of one program as the input of the next.

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.

Re: Pure Bash Bible

#62

Post by sumosudo »

sambe wrote: post #44
jigglesniggle wrote: post #4

While this is interesting I see doing anything but launching programs with simple text-substituted arguments as too much for bash or sh. Run shellcheck on some of your own code, or the code of even a simple project to see how hard it is to really use bash. Why I think people gravitate towards it is because languages such as python add too much pomp to launching a shell process. A language like perl is usually easier…

The overhead of repeatedly launching subshells/processes to do simple operations can add up quickly, especially if it is happening in loops or in parallel. Yes, you shouldn't be using bash for performance, we all know that. But scripts often grow over time and suddenly are found to be slow/resource hogs. I have seen people demand that proper logging be added to a bash program and it then get minutes behind because of…

My favourite way to log.. Redirect stdout and stderr ( &> ) into a named pipe ( >() ) running "tee" And get the redirect into the log file as well. `exec &> >(tee ${__DIR}/${DOC_LOCAL}/${LOG_LOCAL})`

Re: Pure Bash Bible

#63

Post by croo »

I write a bash script or two every month so I thought I'm okay. But then came along the very first example:

  trim_string() {
      # Usage: trim_string "   example   string    "
      : "${1#"${1%%[![:space:]]*}"}"
      : "${_%"${_##*[![:space:]]}"}"
      printf '%s\n' "$_"
  }
Ok, so the : is somehow a temporary variable... Then there is a variable starting at $ and you lost me :D Can someone break down that line for me? What the hell is going on here?

    : "${1#"${1%%[![:space:]]*}"}"

Re: Pure Bash Bible

#64

Post by vghnb »

croo wrote: post #63

I write a bash script or two every month so I thought I'm okay. But then came along the very first example: trim_string() { # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } Ok, so the : is somehow a temporary variable... Then there is a variable starting at $ and you lost me :D Can someone break down that line for me? What the hell is going on…

: is the null command. Kind of like /bin/true. So : followed by anything exists simply to perform expansion on something. If you fully understand what that means, then you will understand this: $_ is simply “whatever the last argument to the previous command expanded to”. So : is the previous command and the ${1… expanded value is now ${_….

Because $_ is used in the expansion of itself, it is the same value, because the command has not yet completed, which would (re) set $_. So use of a thing ($_) in expanding the same thing ($_) is perfectly fine until after that (null) command (:) runs. You see that the final $_ is used standalone. Hope this helps.

Re: Pure Bash Bible

#65

Post by iamnotacrook »

lostmsu wrote: post #54
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…

So PowerShell then?

Isn't that Windows only?

Re: Pure Bash Bible

#66

Post by Evanbenn »

jigglesniggle wrote: post #21
danielecook wrote: post #16

Earlier quoted context omitted.

I don’t think it’s pomp. Once I learned Unix pipes and the tools for manipulating data (sed awk cut etc), it just became much faster and easier than writing python scripts that do the same thing. You can literally connect the output of one process to the input of another with a single character. It’s much more complex in python. It also tends to be very portable.

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…

I think tcl is exactly in this niche. I haven't had time or an excuse to learn it, but it seems to fit perfectly. Haven't yet found out why it seems to be dying away

Re: Pure Bash Bible

#67

Post by hnarn »

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.

Re: Pure Bash Bible

#68

Post by lervag »

croo wrote: post #63

I write a bash script or two every month so I thought I'm okay. But then came along the very first example: trim_string() { # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } Ok, so the : is somehow a temporary variable... Then there is a variable starting at $ and you lost me :D Can someone break down that line for me? What the hell is going on…

I think the idea is that the `:` builtin allows expansion of arguments without actually doing anything else. However, the temporary variable $_ is filled with the content of the expression. That is, after the first

    : "${1#"${1%%[![:space:]]*}"}"
The $_ temporary variable contains the result of removing the leading spaces. In the next line, the spaces at the end are removed from the temporary variable with the "${_%..." syntax.

You can test this in your own shell by e.g. doing:

    : $PATH
    echo $_

Re: Pure Bash Bible

#69

Post by emmelaich »

croo wrote: post #63

I write a bash script or two every month so I thought I'm okay. But then came along the very first example: trim_string() { # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } Ok, so the : is somehow a temporary variable... Then there is a variable starting at $ and you lost me :D Can someone break down that line for me? What the hell is going on…

I don't like this function very much but here's a few notes...

: is a "do nothing" command -- but the line is still evaluated

%% means to replace leading chars that match pattern

## means replace trailing chars

I don't know why they're using $_; thats the variable containing the interpreter name, i.e. "/bin/bash" [edit - also the name of the previous command!]

I can't be bothered analyzing it any further :-)

Re: Pure Bash Bible

#70

Post by vghnb »

emmelaich wrote: post #69
croo wrote: post #63

I write a bash script or two every month so I thought I'm okay. But then came along the very first example: trim_string() { # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" } Ok, so the : is somehow a temporary variable... Then there is a variable starting at $ and you lost me :D Can someone break down that line for me? What the hell is going on…

I don't like this function very much but here's a few notes... : is a "do nothing" command -- but the line is still evaluated %% means to replace leading chars that match pattern ## means replace trailing chars I don't know why they're using $_; thats the variable containing the interpreter name, i.e. "/bin/bash" [edit - also the name of the previous command!] I can't be bothered analyzing it any further :-)

After the first command, $_ expands to whatever the last argument to the previous command expanded to. In this case the previous command was : and the only argument is by definition the last. This is how you chain things together without clunky temporary variables.
Post reply on HN