Live data from Hacker News

Ask HN: How can I get better at bash?

news.ycombinator.com

181–190 of 195 posts

Re: Ask HN: How can I get better at bash?

#181

Earlier quoted context omitted.

ls | while read file; do echo "$file"; done ... works better for the easy edge cases, but still probably has some issues. Personally I think klodolph called it; once you get into anything that has a few interesting edge cases bash becomes pretty unwieldy.

The easiest way is still: for file in *; do ...; done This works fine with spaces and other strange characters, no need to come up with more complicated ways. If you must use find, the correct way is really tricky and uses obscure bash features like settings IFS to the empty string to split on null bytes and process substitution so that the loop doesn't run in a subshell (which would prevent it from modifying variabl…

I like that, I've never thought of or seen it, although it should've been intuitively obvious given how bash expansion works.

I think this demonstrates the point pretty well though - it takes a discussion among three of us before arriving at something that works moderately well, and we found four fairly different ways of doing it...

Re: Ask HN: How can I get better at bash?

#182
post #173
post #101

As silly as it sounds, when I was a new Unix SysAdmin, I read the entirety of "man 1 bash", which includes all bash builtins. I found that it improved by bash-foo 100x simply by knowing about so many of the utilities. I also took some cliff notes for things that seemed generally useful. I did it for an hour or so a night for a week or so. That being said, a few of my personal favorites to memorize: * Parameter expans…

>All of test(1) as you can use them in any if statement (/usr/bin/[ is a real command!): Yes, and not only in an if statement. You can also use test or [ command in commands of the form: test condition && commmand2 or test condition || command2 which will only work if the condition is true or false, respectively (IIRC, need to check this).

That is correct, no need to check on this. I've done this for years :)

Re: Ask HN: How can I get better at bash?

#183
post #182
post #173

Earlier quoted context omitted.

>All of test(1) as you can use them in any if statement (/usr/bin/[ is a real command!): Yes, and not only in an if statement. You can also use test or [ command in commands of the form: test condition && commmand2 or test condition || command2 which will only work if the condition is true or false, respectively (IIRC, need to check this).

That is correct, no need to check on this. I've done this for years :)

Thanks. Well, I was nearly 100% sure too (been using Unix for years too (from before Linux was created)), but "nearly" is not 100% (since I don't use that feature often), and don't like to make claims I am not sure about without a disclaimer, hence I made one :)

Re: Ask HN: How can I get better at bash?

#184
post #155

Earlier quoted context omitted.

What is a good learning resource for what the basic Unix process model (i.e. what you are describing?) Do you recommend a book or something like that? And preferably for a beginner?

Stevens - Advanced Programming in the Unix Environment Love - Linux System Programming The Unix-Haters Handbook (Unfortunately, the best resource ever for this kind of stuff, from which I learned, does not have an English translation.)

Thanks man.

Re: Ask HN: How can I get better at bash?

#185
post #129
post #101

As silly as it sounds, when I was a new Unix SysAdmin, I read the entirety of "man 1 bash", which includes all bash builtins. I found that it improved by bash-foo 100x simply by knowing about so many of the utilities. I also took some cliff notes for things that seemed generally useful. I did it for an hour or so a night for a week or so. That being said, a few of my personal favorites to memorize: * Parameter expans…

Also CTRL-_ which is "undo whatever you just typed"

I was using CTRL+C to open new prompt instead of undoing. Thanks for this.

Re: Ask HN: How can I get better at bash?

#186
post #155

Earlier quoted context omitted.

Stevens - Advanced Programming in the Unix Environment Love - Linux System Programming The Unix-Haters Handbook (Unfortunately, the best resource ever for this kind of stuff, from which I learned, does not have an English translation.)

What resource was that?

The notes by my OS lab professor, written in Romanian, with self-learning in mind, with detailed explanations of the workings of major system calls and featuring numerous working examples and pitfalls.

I might translate them some day and put them up on the Internet (if I get his permission and some free time).

Re: Ask HN: How can I get better at bash?

#187
https://www.gnu.org/software/bash/manual/bash.txt

I like bash for the same reason I like emacs, in that no matter what the environment is like, I can usually count on my bash scripts to work. I keep them in emacs org-mode files where I store them in src code blocks. I can tangle multiple code blocks into single executable scripts to different directories. Check out org-mode babel, tangeling, and noweb. Keeping all my bash code in a single file solves my issue with having to dig for that one script I wrote that one time because I forgot how to do this one thing ...

If you aren't running Linux on your desktop yet, consider it. Full immersion is a fast way to learn.

Re: Ask HN: How can I get better at bash?

#188
post #118

First, if your bash script grows beyond about ten lines, it's time to consider rewriting it in a cleaner language. Python's a common one. I used to use Haskell for that kind of scripting as well, which was astonishingly good at it. Here's my study suggestion: 0. Learn to use variable interpolation and backticks. 1. if blocks and the [ built-in function. Go read about the grammar and look at the flags that [ takes. Me…

> if your bash script grows beyond about ten lines, it's time to consider rewriting it in a cleaner language Just because you don't feel comfortable writing long scripts doesn't mean you should discourage others. There are many many justifications for sticking to shell, for example if you need to write a portable installer that works across every UNIX variation.

> Just because you don't feel comfortable writing long scripts doesn't mean you should discourage others.

And deprive them of the hard learned lessons from decades of experience?

> There are many many justifications for sticking to shell, for example if you need to write a portable installer that works across every UNIX variation.

Do you mean every Linux variation? Because trying to write shell portable from old HP-UX to Darwin is an exercise in insanity.

Re: Ask HN: How can I get better at bash?

#190
This doesn't work for everyone, but if you find allow yourself time, trying to solve specific problems you face (asking: could I automate this? Could this be simpler?) is a great way to get better - and how I learnt my way through bash.

I recently released https://terminal.training (paid course for 4 hours) which is just for this kind of question, but I've also started a free mini email course (same URL) that tries to share some of the CLI shortcuts I've come to rely on over the years.

Post reply on HN