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/
(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]