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

231–240 of 258 posts

Re: Pure Bash Bible

#231

Post by jascii »

dec0dedab0de wrote: post #230
jascii wrote: post #221

Earlier quoted context omitted.

Nice recursive definition.. The practice of programming in shell languages was well established when Bash was designed and Bash was definitely designed with that use in mind. So by your definition Bash is a "real" programming language. Lisp on the other hand, was much more designed as a system and formal notation to reason about certain classes of logic problems.. So, Lisp is not a "real" language?

Bash is primarily a shell, it even has the word shell in its full name.

And a shell can't be a real language? https://scsh.net/

Re: Pure Bash Bible

#232

Post by flukus »

unixhero wrote: post #112
lordfoo wrote: post #101

Earlier quoted context omitted.

Would you mind expanding on this with an example? I'm trying to improve performance of my bash logging

+1. My goal is to learn how to robustly do any logging whatsoever. Eager to learn new tricks.

Do you just want to log the scripts execution or do you want something more structured? If it's the former you can redirect the output from within the bash script with this (apologies for any condescension, I'm not familiar with your skill tree):

  if [ ! -t 1 ]; then
    exec > /my/log/file 2>&1
  fi
The if statements tests if your at an interactive prompt, if your not all output from the script get's redirected to /my/log/file. The above poster is instead redirecting into a subprocess " > (tee)" that will both print the output and log it.

It should be noted that often the bottleneck is the terminal itself, try running your scripts with a "> /dev/null" to suppress output and verify the slow part is actually the script.

Re: Pure Bash Bible

#233

Post by munk-a »

xelxebar wrote: post #229
munk-a wrote: post #195

Earlier quoted context omitted.

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…

Other people mention constrained environments, but tight loops are also a thing. If you know bash's parameter expansion well, it can make it really easy to write a one-liners that speedily process large amounts of output. Setting up and tearing down a whole process (e.g. sed) can cause an order of magnitude slow down, which is significant if you just want something quick and dirty.

I feel like... maybe? But quick or dirty should be enough - you could also build a python interpreter once to map over the data and then maybe write up some tests to confirm the functionality.

Every explanation of why to use bash here seems like it's got a whole lot of constraints on when it's a good to use - I've finished some tasks just in bash scripts but when I'm writing something for anything other than one time passes it seems like more of a maintenance liability than anything else.

Re: Pure Bash Bible

#234

Post by kamaal »

masklinn wrote: post #185
kamaal wrote: post #168

Earlier quoted context omitted.

Of course, if you plan to use one $language alone, you can do anything in that $language. This question is specific to pipes.

> Of course, if you plan to use one $language alone, you can do anything in that $language. That's missing what I'm noting though, which is that you don't need pipes anywhere near a shell script if you can simply do more of your work in-language. Case in point being that the entire pipeline you cited as an issue has no reason to exist outside of a shell or shell script.

That's because regexes are an another pain in Python, You have to write a lot of boiler plate exception handling code. Plus the same boiler plate code for file operations.

It doesn't feel like the language was designed for these tasks.

Re: Pure Bash Bible

#235

Post by kamaal »

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

On the contrary regexes were invented because you shouldn't have to write 500 lines of code for that which can be done in two lines.

If we didn't have regexes we would have 100s of if/else's scattered all over program logic. That would be more hard to handle than the regex itself.

Re: Pure Bash Bible

#236

Post by xelxebar »

munk-a wrote: post #233
xelxebar wrote: post #229

Earlier quoted context omitted.

Other people mention constrained environments, but tight loops are also a thing. If you know bash's parameter expansion well, it can make it really easy to write a one-liners that speedily process large amounts of output. Setting up and tearing down a whole process (e.g. sed) can cause an order of magnitude slow down, which is significant if you just want something quick and dirty.

I feel like... maybe? But quick or dirty should be enough - you could also build a python interpreter once to map over the data and then maybe write up some tests to confirm the functionality. Every explanation of why to use bash here seems like it's got a whole lot of constraints on when it's a good to use - I've finished some tasks just in bash scripts but when I'm writing something for anything other than one time…

Meh. Choose your poison. As the trope goes, "No language is good at everything." Python is verbose compared to bash for many tasks, and the reverse is true as well.

IMHO, spending the time to actually learn some bash can really improve one's CLI life. Bashing on bash seems mostly like a tired ol' trope, "If it's in bash, it's bad."

The author of the original article really has written some pretty shell code!

Re: Pure Bash Bible

#237

Post by 5Qn8mNbc2FNCiVV »

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

And it doesn't have to be. There should be trust that the function does what it says. If I use `printf` and don't understand how it's working internally it doesn't matter to me because I know what it does and trust it.

These scripts/snippets for me are just an unofficial extended standard lib

Re: Pure Bash Bible

#238

Post by papito »

serhart wrote: post #228
papito wrote: post #192

Earlier quoted context omitted.

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 is it not a matter of familiarity? Just because it's not intuitive to you doesn't mean it's bad. I find anything not in an S-expression to be atrocious. Doesn't mean I can't learn and understand "horrible" syntax where I have to separate things with semicolons...

I am saying, we are allowed to have an opinion on it. You can be good at something and still acknowledge that is sucks.

Re: Pure Bash Bible

#239

Post by yesenadam »

shrimp_emoji wrote: post #180
mankyd wrote: post #149

Earlier quoted context omitted.

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.

    echo {1..5}
is even nicer. Or

    echo {1..5}{1..5}{1..5}
Post reply on HN