Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 10 submissions in the queue.
posted by LaminatorX on Sunday October 12 2014, @09:19AM   Printer-friendly
from the Bad-Ass-Script-Host dept.

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.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by No.Limit on Sunday October 12 2014, @10:29AM

    by No.Limit (1965) on Sunday October 12 2014, @10:29AM (#105012)

    Just a few things that caught my eye:

    • The examples always use the shebang [wikipedia.org] '#!/bin/bash', whereas it's totally sufficient to use '#!/bin/sh'. bash offers much more functionality over the normal shell, but that's mainly ui functionality. The normal shell is totally sufficient, but much simpler (and thus might leave a smaller attack vector *cough*shellshock*cough*). You could also go for '#!/usr/bin/env sh' because of "portability" [wikipedia.org].
    • Backticks "`" are nice for using embedded shells, but for embedded shells '$(CODE_HERE)' works too and allows for nesting which comes in useful sometimes.
    • For the last example one could also use the 'watch' command which would be much more elegant.

    And as has been said before this isn't really news, but rather some shell scripting tutorial for looping.

    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by ticho on Sunday October 12 2014, @10:42AM

    by ticho (89) on Sunday October 12 2014, @10:42AM (#105018) Homepage Journal

    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

      by tynin (2013) on Sunday October 12 2014, @10:51AM (#105019) Journal

      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

    by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Sunday October 12 2014, @11:41AM (#105029) Homepage
    His examples were also not able to cope with names that had spaces in. All $IFS's look the same to a "for x in ...".
    --
    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

    by theCoder (3583) on Sunday October 12 2014, @12:42PM (#105039)

    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

      by fnj (1654) on Sunday October 12 2014, @04:53PM (#105090)

      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

      by maxwell demon (1608) on Sunday October 12 2014, @05:11PM (#105099) Journal

      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

      #!/bin/sh

      but only

      #! /bin/sh

      --
      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

        by theCoder (3583) on Sunday October 12 2014, @09:02PM (#105264)

        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

    by JoeMerchant (3937) on Sunday October 12 2014, @02:27PM (#105054)

    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

      by fnj (1654) on Sunday October 12 2014, @05:01PM (#105094)

      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?