When I first learned about Linux in the 90’s, I read that it was possible to even write your own commands to use at the command line. Later I learned about bash scripting, and it wasn’t long before I needed to learn how to loop in bash. Looping in bash is one of the fundamental building blocks of bash programming. It isn’t hard to do at all and is worth learning. The main reason to learn looping in bash is to handle doing the same thing over and over again. They’re easy to do even at the command line. Please follow along as we look a couple of basic examples, and how you can expand on them.
http://www.tidbitsfortechs.com/2014/10/looping-in-bash/
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(Score: 2, Insightful) by Rosco P. Coltrane on Sunday October 12 2014, @09:53AM
Not to nitpick or anything - it's great that people discover new and exciting things - but how is this news, let alone interesting news? This is shell scripting 101...
I was expecting an article on loopHOLES in Bash, not an introductory course on basic algorithmics.
(Score: 0) by Anonymous Coward on Sunday October 12 2014, @10:34AM
its interesting and nerdy, and news shouldn't just be about sensationalized bs... there's plenty of other sites for that
SN is about community as well as news, and sharing tips and tricks, reviews, asking questions etc are all perfect for engaging discussion
everyone is welcome to also share their opinion of course, which is also great
(Score: 0) by Anonymous Coward on Sunday October 12 2014, @10:41AM
Indeed. LaminatorX should have done a little bit of research before posting this "news story". A simple google search for "bash script" would have turned up millions of hits. This is not news. Not even close.
(Score: 2) by theluggage on Sunday October 12 2014, @11:07AM
This is not news. Not even close
But... "bash" is a trending keyword at the moment, and surely the language every l33t haX0r wants to learn right now. I hope part 2 of this article covers how to embed loops in environment variable declarations.
P.S. Heartbleed had a logo. Where's the shellshock logo? I thought every security vulnerability got a snappy name and a logo now?
(Score: 0) by Anonymous Coward on Sunday October 12 2014, @02:38PM
Here you go... [twimg.com]
(Score: 0) by Anonymous Coward on Monday October 13 2014, @02:08PM
(Score: 2, Insightful) by Anonoob on Sunday October 12 2014, @12:11PM
The 'millions of hits' itself is important point here - even the few comments so far have given those of us in the 101 camp some insights, that may not be immediately resolved fishing through those hits. Can readily agree it isn't news, but who really comes to SN for the articles. Sure I can go learn this on other sites, but the opinions it was basic non-news actually peaked my interest, while later comments on different techinques were something the article itself did not go into and shows the true value of this site.
So I for one, would appreciate this kind of article being posted now and then.
(Score: 2) by Phoenix666 on Monday October 13 2014, @01:38PM
I second this, too. Most of the time when you don't fish in certain waters all the time you chug through a tutorial to get what you need, and move on. This kind of focused feedback gives very valuable context to scripting in general that you would be hard pressed to get any way other than by sitting among the greybeards in the dark rooms for several years.
Washington DC delenda est.
(Score: 5, Insightful) by BsAtHome on Sunday October 12 2014, @11:22AM
While I can relate to the sentiment of this not being news, this site should welcome diversity. Please remember that you also needed to learn the basics at one point...
The article surely fits into the category "Stuff that matters". New users want to be appreciated too and certainly not mocked for not knowing. They want to learn, you have also learned it and others need to be brought into the breach. We all should politely help each other at the level we can understand and operate. There is no point at making this an exclusive site if you want to reach a broad target audience.
Just my 2 (euro) cents.
(Score: 2) by tangomargarine on Monday October 13 2014, @02:30PM
http://lmgtfy.com/?q=looping+in+bash&l=1 [lmgtfy.com]
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 4, Informative) by maxwell demon on Sunday October 12 2014, @12:15PM
Indeed, it is not even good as tutorial, as it does several things not advisable.
First, the constructs he uses are just regular Bourne shell constructs, yet he uses #!/bin/bash as shebang line. Doing so unnecessarily restricts portability (and since the Shellshock bug should also be avoided for security reasons). He should use #!/bin/sh for portability.
Next, it uses backticks instead of $() for command substitution. Unless you need to run your code on very ancient shells, don't do that. It's too easy to get wrong, and then get unexpected behaviour (a long time ago, I once even inadvertently created a fork bomb this way — I just wanted to output a lot of information from the script, including the script's own name, and an error in the backticks actually caused one of the $0 directly following an opening backtick (which was intended to be a closing one) ...
Next, he is using variables completely without quotes. That's just asking for disaster when any name has a space inside. Now you may argue that the for construct he uses won't work of he puts $names in quotes. But then, the whole idea of storing the output of cat in a variable via command substitution. The right loop to use here would be a while loop using read to get the names from the file.
Also, why does he use /bin/true instead of simply true, although he uses cat and not /bin/cat? Obviously /bin is in his path, or cat would not be found. Not to mention that bash provides a built-in true which almost certainly is more efficient to use that /bin/true.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Informative) by toygeek on Sunday October 12 2014, @08:46PM
OP here. I can address all of your concerns with two words: Simplicity, Habit. Thanks for reading :)
There is no Sig. Okay, maybe a short one. http://miscdotgeek.com
(Score: 2) by Phoenix666 on Sunday October 12 2014, @12:51PM
I welcome this kind of thing because bringing back an element of the old LUGs is a good thing. It sets the site apart from other mindless aggregators. Also, when it comes to technology it's always good to get refreshers, even on basic things. Let's say you haven't done any bash scripting in, oh, ten years. It's good to see it again, and it happens also not infrequently that you can learn something new, some trick, that you never knew but wish you had all this time.
A couple of years ago I had some down time and read a tutorial somewhere about vim scripting. I had once dipped my toe in but since I didn't have a particular use for it at the time never went any further and didn't retain anything. But now I find its use makes me three times more productive and that's awesome.
Washington DC delenda est.
(Score: 3, Interesting) by No.Limit on Sunday October 12 2014, @10:29AM
Just a few things that caught my eye:
And as has been said before this isn't really news, but rather some shell scripting tutorial for looping.
(Score: 2) by ticho on Sunday October 12 2014, @10:42AM
I might be remembering this wrong, but aren't backticks considered obsolete, and to-be-replaced by $(code) construct?
(Score: 2) by tynin on Sunday October 12 2014, @10:51AM
Yeah backticks and also seq are considered obsolete but continue to work. But having used them for so long my fingers kept typing them out for doing for loops for cluster management (e.g. for x in `seq 200`; do ssh 10.0.0.$x "hostname"; done). You save yourself having to type a couple extra characters, granted not many. Only recently did one of my coworkers write this simple yet powerful parallel ssh tool that I've stopped bothering with for loops.
(Score: 2) by FatPhil on Sunday October 12 2014, @11:41AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1) by theCoder on Sunday October 12 2014, @12:42PM
I agree that /bin/sh is preferable to /bin/bash. But to your second point, I do not think the $() syntax is part of the original Bourne shell, and thus might not be as supported by the /bin/sh interpreter. A quick test shows that dash (the /bin/sh interpreter on my Mint system) does support it. And RedHat style systems that use bash as /bin/sh will probably allow it, too. So that likely covers most Linux systems, but others like Solaris and the BSDs might have different compatibility. See Portability Issues [tldp.org] for more information and other features that you shouldn't rely on when using /bin/sh.
(Score: 3, Informative) by fnj on Sunday October 12 2014, @04:53PM
You'll have a tough time finding an sh that does not support $(). BSDs and Solaris have supported it for a long time. It's definitely part of POSIX 1003.1. Having said that, it wasn't part of pre-POSIX Bourne sh. It pleases me to limit my scripts to the syntax of the Heirloom Bourne shell [sourceforge.net], which represents state of the art for SVR4, circa 1989. It is easy to install anywhere; I have it as /usr/local/bin/bournesh on every system. Any script you develop and test with it is going to work with any shell you can find on any running system, period. (Your portability is going to end up depending on the vintage of your /bin utilities - it never ends!). But no one would ever use it as an interactive shell. I mean you CAN and it works fine, but with no command line editing or recall whatsoever, you're going to tear your hair out and bash your keyboard to splinters.
My policy is to never write a bash script; never start with #!/bin/bash. Bash is a terrific interactive shell, but you just don't need $(), (()), [[]], variable arrays, associative arrays, etc. in your scripts. You DEFINITELY don't need "function foo { }". "foo ( ) { }" works fine.
You can even find the source for V7 (1979) sh [collyer.net] modified to compile on modern systems. That was just too primitive IMHO. It didn't have the # comment character; no functions at all; no unset; no set --; no [] (you have to use test); no ! test negation.
Or if that is not primitive enough, how about V6 (1975) Thompson sh [v6shell.org]? I'll let you experiment with it on your own, but I'll just say you ARE going to find a lot of missing stuff.
For that matter, you could try to resurrect the V1 (1971) sh for yourself if you just want to lose your sanity.
The whole fascinating history [in-ulm.de] makes for a good read.
It's a discipline. Everyone can decide the portability/readability/reliability/productibity tradeoffs for himself.
(Score: 3, Informative) by maxwell demon on Sunday October 12 2014, @05:11PM
Given that the $() syntax is part of POSIX, I guess unless you need to target very old systems, there's no reason to use backticks.
Note that on some very old systems, the usual shebang line may not work either, since some old systems checked for the four-byte sequence "#! /", so they would not recognize the commonly found
but only
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by theCoder on Sunday October 12 2014, @09:02PM
Good to know. I didn't realize support was so widespread and standard. I guess I was burned on some older (maybe Solaris 8?) machines, assumed it was a bash feature only, and never tried again.
(Score: 2) by JoeMerchant on Sunday October 12 2014, @02:27PM
I'd say the sh bash choice is just that, a choice. If you are writing to bash and you intend to execute in bash, then use bash. If you only need sh, then go for sh.
What I'd rather work with is a system that uses one, consistently, instead of sh in this file, bash in the next, and csh every so often just to drive you nuts.
🌻🌻 [google.com]
(Score: 2) by fnj on Sunday October 12 2014, @05:01PM
I'm not religiously against anybody scripting in bash as against sh (I limit my own shell scripts to sh, but I'm not a fascist).
But you have to ask yourself, given the power of bash and the accompanying bulk, when you get into heavier duty stuff like array variables, associative arrays, shell math, etc. - why not just make the jump to perl or python and do it right?
(Score: 2) by JoeMerchant on Monday October 13 2014, @03:06AM
Because feature creep is more seductive than the shiny new language...
🌻🌻 [google.com]
(Score: 2) by The Mighty Buzzard on Sunday October 12 2014, @10:33AM
It's going on 2015, shouldn't we be using <names.txt or at least $(cat names.txt) by now?
My rights don't end where your fear begins.
(Score: 1) by b on Sunday October 12 2014, @10:59AM
Yeah, I thought this felt like useless use of cat too, but I'm not sure how it could be improved. I'm not sure how to remove cat from "for i in $(cat foo.txt)".
(FWIW I'd use "while read -r" myself anyway.)
(Score: 2) by Foobar Bazbot on Monday October 13 2014, @01:00AM
9 times out of 10 (i.e. unless one really means to allow multiple iterations per line), the right way to remove cat from "for i in $(cat foo.txt)" is to remove the whole line.
(FWIW I'd use "while read -r" myself anyway.)
You and me both.
(Score: 1) by b on Monday October 13 2014, @11:42PM
(Score: 2) by VLM on Sunday October 12 2014, @11:12AM
There's a minor problem in the article... by trying to start too simply, other better simpler solutions are available.
xargs is for more than screwing around with directories with 100K (quantity not length) files.
Several of the early examples boil down to something equivalent to
ls | xargs wc -l
Another interesting strategy not considered is some simple report-ish tasks are very amenable to awk and awk is fast, faster than Perl (and if you've got a truly awful task, whip out a Perl one liner)
(Score: 2) by FatPhil on Sunday October 12 2014, @11:43AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Sunday October 12 2014, @12:08PM
I think that it would be more correct to state that all sed programs can be implemented in awk. Not the other way around, however for most one-liners I probably agree. AWK is actually a full featured programming language that can do advanced math, has arrays, flow control, file I/O, the works. You can implement most things like bc, sed, grep, in awk.
(Score: 2) by VLM on Sunday October 12 2014, @12:27PM
"advanced math"
Well that might be a little optimistic, but awk is pretty awesome at the fairly typical tasks of "gimme the MAX, MIN, AVG, STD DEV" of some set of ... something.
Reminds me of the project I did some years back importing a medium size engineering dataset into R, then daydreaming of the infinite number of cool things in R, and then nobody wanted anything other than avg, I couldda just left it all in awk...
(Score: 2) by Snotnose on Sunday October 12 2014, @01:30PM
is a book with many more examples. My copy has to be 20 years old, wonder if it's still in print?
It's just a fact of life that people with brains the size of grapes have mouths the size of watermelons. -- Aunty Acid
(Score: 3, Informative) by PizzaRollPlinkett on Sunday October 12 2014, @03:42PM
I recommend O'Reilly's "Classic Shell Scripting" book. I usually have to do bash scripting every few years when someone needs a shell script for some reason and doesn't want a Perl or Python program. If you're used to real programming languages, sh and bash are badly designed and confusing and I never really remember them. (I don't care what you say about Perl, bash has words spelled backwards - did Zatanna design it? The syntax looks like a junk drawer of random stuff taken from every programming language in the 70s. Even REXX makes more sense, and some of the commands have open parens without close parens.) The first thing I do is pull down this book and try to read up on what I need to know.
I have a sample somewhere of looping through an array that I always dig up because it's not obvious. But it's not the hardest thing to remember. There's a "for scalar in array" construct, but the hard part for me has always been getting something into an array.
Anyhow, bugs or not, bash is harmful to my brain and I try to use a real programming language for any script I possibly can.
[!si annataZ ohw wonk uoy epoh I]
(E-mail me if you want a pizza roll!)
(Score: 0) by Anonymous Coward on Sunday October 12 2014, @04:10PM
O'Reilly's
You might want to read this http://thebaffler.com/articles/the-meme-hustler [thebaffler.com]
(Score: 2, Interesting) by hendrikboom on Sunday October 12 2014, @06:31PM
The backwards words are an Algol 68 legacy, and are close brackets that match the correcponding forward-spelled words. The variety of brackets makes it easy to detect, diagnose, and correct missing brackets. I contrast this with C's '}', Pascal's ubiquitous 'END' and Lisp's even more irritating ')'.
-- hendrik
(Score: 1) by Qzukk on Sunday October 12 2014, @09:56PM
Rather than thinking of it as "in array" think of it as "in list" where list is a string of things separated by whatever character(s) in $IFS
(Score: 2) by hemocyanin on Monday October 13 2014, @03:37PM
I consider myself beyond introductory scripting, maybe a weak intermediate. I was sort of confused by the example in the original article because there is a lot of similarity between the ` character and the ' character, especially considering how popular it is use funny single and double quotes in websites these days. At first I just thought this was dealing with a file titled: cat names.txt (with the space) so I gave him kudos for dealing with the space in the filename. Anyway, as others have mentioned, I'm much more used to using "while" for this sort of thing.
As others have said, people come for the comments. What I got out of the comments was the $() bit -- I too would have defaulted to backticks. My next step is to actually understand what the difference between backticks and $() is. Also to the sed and awk posters -- both are great.
(Score: 1) by b on Monday October 13 2014, @11:54PM
Also, I'd quote the variables to work more elegantly with spaces (e.g. don't compress multiple spaces in a string). i.e. use "$LINE".
FWIW, I usually use the -r flag for read, to prevent interpretation of backslashes.
Finally (a minor point), you can use a heredoc instead of the extraneous echo.
(Score: 2) by hemocyanin on Monday October 13 2014, @11:58PM
helpful info -- thank you
(Score: 1) by b on Tuesday October 14 2014, @12:36AM
No worries. Much of it is fairly minor, for edge cases. Still, your code was a hell of a lot better than the tutorial!