Shell Programming and Scripting

Here are a few continue and break examples from source code:

Code:

  for (absNdx_NotAtom = 0; absNdx_NotAtom < absNdx1_Atom; absNdx_NotAtom++) {
    pckNdx = RWV_GEO_Abs_PckNdx___Array_g [absNdx_NotAtom];
    if (pckNdx < 0) {
      continue; // NOT picked
      }
    /* Many additional processing steps */
    }

Code:

    for (rowNdx = 0; rowNdx < rowCntOmitSum; rowNdx++) { // Do sum
      if (possiblySkipRow_IfAgeAdjustTicVar == TRUE) {
        if (RowVarNdx_EvtArrays_g == cryVarNdx_Age) {
          if (i64Array == RWA_I64_Pop_Denom________g) {
            if (OmitRowFromPopTotals_g [rowNdx] == TRUE) {
              continue;
              }
            }
          }
        }
      /* Many additional processing steps */
      }

Code:

  while (1 == 1) {
    eightBitNumber = (int) (numberToUse % 128);
    numberToUse /= 128;
    if (numberToUse > 0) {
      eightBitNumber |= 0X80;
      }
    binaryDataArray [0] = eightBitNumber;
    fwrite (binaryDataArray, 1, 1, binWtr);
    if (numberToUse == 0) {
      break;
      }
    }

Code:

  while (1 == 1) {
    items = fread (binaryDataArray, 1, 1, binRdr);
    eightBitNumber = binaryDataArray [0];
    sevenBitNumber = eightBitNumber & 0X7F;
    intRead += (sevenBitNumber * factorUsed);
    factorUsed *= 128;
    if ((eightBitNumber & 0X80) == 0) {
      break;
      }
    }

The isolated examples probably mean little or nothing to you. The point is programmers use break and continue all the time in situations not processing user input.

Here is a simple example using bash, showing how break and continue make sense:

Code:

while read field_1 field_2; do
  if [ $field_1 = "skip_me" ]; then
    continue
  fi
  if [ $field_1 = "bail_out" ]; then
    break
  fi
done

You are right that break and continue are often useful for processing user input. But there are obviously many kinds of input. Input from data files. Input from arrays. Input from strings. Input from numbers. Perhaps other inputs. Those other inputs also have to be read in some way, and break / continue are helpful for processing those other inputs too. There is no "special connection" between reading user input and continue/break.

Assume you have a loop, and you have a condition to stop executing that loop before it reaches its boundaries - break out in the middle of the loop. Use continue to skip the execution of the remaining body of the loop for that single iteration:

Code:

$ awk 'BEGIN {while (i++ < 100000) {if (i==3) continue; print i; if (i==5) break}}'
1
2
4
5

The "program" in your 1st posting is not a valid shell script (although most shells will accept it without complaining. The only valid uses of break and continue are when they are used within a for loop, an until loop, or a while loop. If the script you posted:

Code:

echo "Wanna continue (y/n):\c"
read answer
if [ "$answer" = y ]
then
continue
else
break
fi

is run using bash on OS X, it will either say:

Code:

filename: line 7: break: only meaningful in a `for', `while', or `until' loop

or:

Code:

filename: line 5: continue: only meaningful in a `for', `while', or `until' loop

By the logic you're using above and the shell program below:

Code:

printf "Wanna continue (y/n): "
read answer
if [ "$answer" = y ]
then    exit 0
else    printf "This script will continue.\n"
fi
... ... ...

there is a link between read, exit, and printf (or any other utilities you happen to execute if the value of a condition based on the value of a variable is true or false.

What I was saying about awk is that it can be used interactively or non-interactively. I can also say that bash, ksh, and perl can be used interactively or non-interactively. I have seen a sudoku game that reads the initial values from a file and then interactively reads commands from the user to set open positions to values supplied by the user (and optionally notes all values that could be entered into any unset position based on values that have already been set in that position's quadrant, row, and column). I have seen a similar sudoku game written in ksh93. I have a lot of shell scripts that perform non-interactive updates to homegrown databases (sometimes invoking awk to perform some of the work). Classifying awk, bash, ksh, or perl as interactive or non-interactive seems to me to just show a lack of imagination.

There are many non-interactive scripts where I would find all of the above tools to be bad choices depending on what the script is supposed to do. There are many interactive scripts where I would find all of the above tools to be bad choices depending on what the script is supposed to do. There are many interactive and non-interactive scripts where any or all of the above tools would be good choices depending on what the script is supposed to do.

Look at the requirements for a project and choose appropriate tools to fulfill those requirements. Don't restrict the tools you have in your toolbox based on someone's predefined notion of how those tools are most frequently used.

And hanson44 has just supplied you with several real life examples of using break and continue in loops. Whether these uses are interactive or non-interactive depends on where the input is coming from and what else is going on in the code before and after the given fragments.

Don Cragun, I have intentionally written only the read,continue and break statements . I knew the code I wrote should be within a loop(while, for, until) then only 'continue' and 'break' makes sense. In awk also , if continue and break are written without loop, it will show error. I knew all these. I thought a reader would understand that I am writing a sub-part of a loop. So, I intentionally skipped writing the loop (while or for). It should have been tacitly understood that the code I wrote is a part of a loop because then only what I am saying becomes meaningful. If 'loop' was not in my mind and simply I am writing 'continue' and 'break', it makes no sense of what I am saying.

By the way, thanks for the examples. I will go through later.

I tacitly understood the initial code was part of a loop. Personally, if I said anything too strong, I apologize. We're all just trying to help. Thank you for posting, and the discussion.

hanson44 , those isolated examples were more than enough to understand what I wanted to know. Thanks a lot!

Rudic, I got it from your simple code what I wanted. Thanks!!

In these kinds of fora, others can judge your level of understanding only through what you mention in your posts; rarely anyone knows anybody else personally to make any appropriate presumptions.
So, it's always better to mention such things explicitly rather than let others play a guessing game about your competence level.