How about you don't? Bash as scripting language is rather mediocre. Anything that is not simple in bash gets hard to read and debug and probably is wrong on some subtle levels. I have a rule of thumb that any shell script that grows beyond a screenful of lines gets redone in a proper scripting language.
Ask HN: How can I get better at bash?
21–30 of 195 posts
Re: Ask HN: How can I get better at bash?
#22How about you don't? Bash as scripting language is rather mediocre. Anything that is not simple in bash gets hard to read and debug and probably is wrong on some subtle levels. I have a rule of thumb that any shell script that grows beyond a screenful of lines gets redone in a proper scripting language.
OTOH, if you can structure your problem as a composition of pipelines, it can be quite a bit faster in bash than in a "proper" language. You get to choose optimized tools, and they run concurrently. Writing efficient bash code forces you to think about your problem differently. It's a very similar process to thinking functionally; e.g. you don't want to deal with lines of a file one at a time in a loop, you want to d…
I would love something like that.
Re: Ask HN: How can I get better at bash?
#23Re: Ask HN: How can I get better at bash?
#24I used to lean on python for much of my scripting needs, mainly because the more advanced bash syntax was pretty daunting. Getting better at bash has a trickle-down effect, especially in this container age. ENV var scoping + loops and various var expansion methods really made it click for me. Shelling out to various tasks (and grabbing the results) is effortless via bash scripts. With bash on windows now it's pretty…
The Bash syntax is not daunting, or if it is that's never been the problem with Bash. The problem is that Bash or shell programming in general gives you a million ways to shoot yourself in the foot and maybe one or two obscure, funny-looking ways to do what you want. Like iterating over the files in a directory, for example. If you think that's easy in Bash you have either have a funny definition of easy or you're forgetting a few corner cases. Or getting the output from a program—did you know that $(my_prog) or `my_prog` modifies the program output?
For containers we do everything declaratively.
Re: Ask HN: How can I get better at bash?
#25Earlier quoted context omitted.
OTOH, if you can structure your problem as a composition of pipelines, it can be quite a bit faster in bash than in a "proper" language. You get to choose optimized tools, and they run concurrently. Writing efficient bash code forces you to think about your problem differently. It's a very similar process to thinking functionally; e.g. you don't want to deal with lines of a file one at a time in a loop, you want to d…
Is there a "proper scripting language" somewhere that supports the same first-class access to Unix programs and the same piping | syntax that shells in general do? I would love something like that.
Re: Ask HN: How can I get better at bash?
#26echo "345.44
544.50" | rg "€#{l}: €#{(l.to_f * 3).to_i}"
Produces the following output:
€345.44: €1036
€544.50: €1633
Based on this code:
https://gist.github.com/zachaysan/4a31386f944ed31a3f8a920c85...
I find it's much faster to be productive like this than it is to try to do the same with ruby -e because I really only want to manipulate single incoming lines. I don't want to have to write the looping code or the code that sets variables or what have you.
Also, sometimes it gets confusing what tools are just bash functions or alias and which are scripts, so if you ever forget what a tools definition is just type:
type toolname
As for actually answering your question, look at your friend's dotfiles on their github account to learn which tools and tricks they use and when you don't know how something works ask them questions. People will usually point you in the right direction.
Re: Ask HN: How can I get better at bash?
#27How about you don't? Bash as scripting language is rather mediocre. Anything that is not simple in bash gets hard to read and debug and probably is wrong on some subtle levels. I have a rule of thumb that any shell script that grows beyond a screenful of lines gets redone in a proper scripting language.
Since when is simplicity an argument against writing programs? Whether scripts or frameworks? "Hard to read" is not neccessarily an inherent trait[1] of the language, and more likely wrong on some PEBKAC level.
I have a customised environment at near 10k lines of bash in 5 projects, all of it in the correct tool for the job, aka a proper scripting language, so I can suggest another use for your thumb :-)
1: https://www.reddit.com/r/commandline/comments/2kq8oa/the_mos...
Re: Ask HN: How can I get better at bash?
#28In any programming language, you learn by practice. Given that your shell does so much, that's the easiest place to find tasks to practice on. I have been leaning on my shell scripts to do a lot of automation. The list is long and I just pick something from that list to work on for most days.
If you don't have system automation that you want to work on, then you probably have a lot of personal data that you can work with. I have scripts setup to manipulate data exports from the various services I consume and then remix that data in my own database. My shell scripts can get the data, operate on it and then shove it into a DB. Then I'll use something else to display that data.
Re: Ask HN: How can I get better at bash?
#29Earlier quoted context omitted.
OTOH, if you can structure your problem as a composition of pipelines, it can be quite a bit faster in bash than in a "proper" language. You get to choose optimized tools, and they run concurrently. Writing efficient bash code forces you to think about your problem differently. It's a very similar process to thinking functionally; e.g. you don't want to deal with lines of a file one at a time in a loop, you want to d…
Then you have the age old problem: what if one of the tasks in your pipeline(s) fails?
set -o pipefail -o errexit
Add more options to taste.Re: Ask HN: How can I get better at bash?
#30I invite you to read about it: http://doc.cat-v.org/plan_9/4th_edition/papers/rc.
I find the control structures simpler and more elegant, and overall its design feels more consistent. For example, consider an if statement in bash:
if [ condition ]; then
...
else
...
fi
And now in rc: if (condition) {
...
} else {
...
}
Or a case statement in bash: case $1 in
"bar")
... ;;
"baz")
... ;;
esac
And expressed in rc: switch ($1) {
case "bar"
...
case "baz"
...
}
In the past, I've used it as my shell too, but now I use it only for scripting. I think you can install it in most platforms.