Chapter 10. Shell Scripting Functions

In writing shell scripts, you will often find yourself repeating the same code over and over again. Repeatedly typing the same code can be tiring and can lead to errors. This is where shell scripting functions should be used. Shell functions are used to simplify your shell scripts, making them easier to read and maintain.

Shell functions are like a magic box: You throw some things into it, it begins to shake and glow with a holy aura, and then out pops your data, magically changed. The magic that is performed on your data is a set of common operations that you have encapsulated into the function and given a name. A function is simply a way of taking a group of commands and putting a name on them. The bash man page describes functions as storing "a series of commands for later execution. When the name of a shell function is used as a simple command name, the list of commands associated with that function name is executed."

Other programming languages call functions subroutines. In essence they are atomic shell scripts, having their own exit codes and arguments. The main difference is that they run within your current shell script. This means that you have one instantiation of the shell, rather than spawning a new instance of the shell for each function. Instead of defining functions, you can put your functions into separate shell scripts, in separate files, and then run those scripts from within your shell script. However, this means you have to maintain a number of individual files, and that can get messy.

This chapter covers the following topics:

  • Defining and using functions

  • Using arguments and returning data from functions

  • Function variable scope

  • Understanding recursion

Defining Functions

The syntax for defining functions is not complex. Functions just need to be named and have a list of commands defined in the body. Choose function names that are clear descriptions of what the function does and short enough that they are useful. In bash, a function is defined as follows:

name () { commandlist; }

This function is very dry, but it illustrates the syntax of the most basic function definition. The name of the function is name. It is followed by a required set of parentheses that indicates this to be a function. Then a set of commands follows, enclosed in curly braces, each command separated by semicolons. The space immediately following the first curly brace is mandatory, or a syntax error will be generated.

The curly braces surround what is known as a block of code, sometimes referred to as the body of the function. A block of code combines several different commands into one unit. Anything that is contained in a block of code is executed as one unit. Blocks of code are valid shell scripting constructs outside of functions.

For example, the following is valid bash syntax defining two distinct blocks of code:

$ { ls -l; df -h; } ; { df -h; ls -l; }

If you were to type this rather useless bit of shell code into the shell and run it, you would find that the first block of code has both its commands executed in order, and then the second block of code has its two commands executed in order.

Blocks of code behave like anonymous functions; they have no name, and unlike functions, variables used in blocks of code are visible outside of the function. So if you set a value to a variable in a block of code, it can be referenced outside of that block of code:

$ { a=1; }
$ echo $a
1

Blocks of code are not functions because they have no names and because their variables are visible outside of the block. They are useful for combining sequences of commands, but they cannot be replicated without retyping the block of code.

Adding Names to Blocks of Code

A function is simply a block of code with a name. When you give a name to a block of code, you can then call that name in your script, and that block of code will be executed.

You can see how functions work by defining a basic function in the shell.

Try It Out: A Basic Function

Type the following in a bash shell:

$ diskusage() { df -h; }

How It Works

After you type this line and press Enter, you are returned to the shell prompt, and nothing is printed to the screen unless there was an error in your syntax. You've just defined your first simple function. The name of the function is diskusage, and the function runs the command df -h when it is referenced.

You can see the function that you have just declared by using the built-in bash command declare with the -f flag:

$ declare -f diskusage
diskusage ()
{
    df -h
}

Notice that the shell has reformatted the function. It's actually more readable like this, and when you write functions in shell scripts, it is good programming practice to format your functions like this for legibility.

If you put more than one command in your function's block of code, separate each command with a semicolon, and end the list of commands with a final semicolon. For example, the following function places three separate commands in the code block:

$ diskusage () { df; df -h ; du -sch ; }
$

When you print out the function in the shell using the declare shell built-in command, you will see how multiple commands look when they have been formatted:

$ declare -f diskusage
diskusage ()
{
    df;
    df -h;
    du -sch
}

You can declare a function on the command line using the shell's multiline input capability.

Try It Out: Multiline bash Function Declaration

Type diskusage () and then press the Enter key to begin declaring this function:

$ diskusage ()
> {
> df
> df -h
> }
$

Note how the commands that are placed within the command block do not have a semicolon after them. It is perfectly legal to omit the semicolon in a multiline function declaration, as the newline is interpreted as the end of the command. You must include a semicolon in single-line declarations because without it the shell does not know when one command ends and another begins.

How It Works

The shell's multiline input capability kicks in after you enter the first line by prompting you with the > character. The shell knows that there is more to the function that you are inputting and so is prompting you to continue. When the shell encounters the } character, it knows that the function has been fully entered, and it returns you to the standard shell prompt.

Function Declaration Errors

It is easy to incorrectly declare and use functions. Because everyone does it, it is good to know what the most common syntax mistakes and their resulting errors are so you can recognize them and fix them.

If you forget to include the parentheses in your function declaration, the error you receive will not tell you that; it will instead be confused by the unexpected curly braces.

Try It Out: Function Declaration Errors

Incorrectly define the function diskusage without using parentheses:

$ diskusage { df -h ; }
bash: syntax error near unexpected token `}'

How It Works

Bash attempts to parse this and does not have any idea that you are trying to declare a function, so its error message is a little cryptic. Watch out for this; it means that you forgot to include the required parentheses in your function declaration.

Another common error is encountered when specifying the contents of the code block. If you do not put the proper spaces between the curly braces and the commands, bash will be confused about what you are trying to do.

Try It Out: Function Formatting Errors

Use bad formatting to declare the diskusage format, omitting the required spaces within the curly braces:

$ diskusage () {df -h;}
bash: syntax error near unexpected token `{df'
$ diskusage () { df -h;}
$

How It Works

The first attempted function declaration neglects to include the required space that must immediately follow the first curly brace. Without that space, bash gives you an error because it isn't expecting what it finds. The second command puts the initial space after the opening curly brace but does not include a space immediately before the closing curly brace; because this is valid syntax, bash does not complain, and the declaration works. You do not need that final space, but it makes your functions more readable and is a good standard to adopt.

Using Functions

To use a function that you have declared is as simple as executing a command in the shell, using the name of the function as the command.

Try It Out: Using Functions

You can execute the diskusage function that you declared in the shell in the previous section by simply typing the command in the shell in which you declared the function:

$ diskusage
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hdb3               474474    235204    214771  53% /
...

How It Works

Calling the function that you declared causes the shell to execute the commands enclosed in the code block of the function. In this case, disk usage commands were placed in the code block, so the output of the df command specified is printed to the screen.

This function has been defined in the currently running shell, and it is available there only. After you have defined a function, it is known in the shell you defined it in, as well as any subshell started by that shell. Additionally, a function is available only in the shell script that you define it in and not in any others, unless you define it there as well. See how this works in this Try It Out.

Try It Out: Function Availability

Open a new shell, different from the one you defined the diskusage function in from the previous Try It Out, either in another window or by simply typing bash in your current shell. Now attempt to call the diskusage function you defined in the other shell:

$ diskusage
bash: diskusage: command not found

How It Works

You get an error about the command not being found because the diskusage function was declared in the other shell, and it is not available in this new shell—only in the shell instance where you defined it. This is covered later in the chapter under the discussion of function scope.

Declaring before Use

When you define a function, the commands that are in the block of code are not executed. The shell does parse the list of commands to verify that the syntax is valid, and if so, it stores the name of the function as a valid command.

As demonstrated in the previous section, the shell must have the function name stored before it can be called, or there will be an error. This means that a function must be known by a shell script before it can be used; otherwise, it is an unknown command. You should always make sure that your functions are declared early in your shell scripts so that they are useful throughout the rest of your scripts. The following Try It Out shows what happens when you try to call a function before declaring it.

Try It Out: Calling Functions before Declaring Them

Put the following basic script into a file and call it functiondisorder.sh:

#!/bin/sh

diskusage

diskusage() {
  df -h
}

Now make this script executable by running the following command:

$ chmod +x functiondisorder.sh

Finally, run the script:

$ ./functiondisorder.sh
./functiondisorder.sh: line 3: diskusage: command not found

How It Works

As you can see from the output of running this script, the function diskusage was not known before it was used, so it generated an error. If the function is moved to the beginning of the script, before it is referenced, it will run properly.

The order of your function declarations does not matter as long as they are declared before they are called, as demonstrated in the following Try It Out.

Try It Out: Proper Function Order

Put the following text into a file called functionorder.sh:

#!/bin/sh

quit () {
  exit 0
}

greetings () {
  echo "Greetings! Thanks for running this function!"
}

greetings
quit
echo "The secret message is: You will never see this line."

Now make this script executable by changing the mode to have the execute bit set:

$ chmod +x functionorder.sh

And finally, run the script to see what it outputs:

$ ./functionorder.sh
Greetings! Thanks for running this function!

How It Works

The shell parses the shell script and loads the functions that are defined at the beginning. It does not care in what order you are going to call them, so putting one before the other causes no errors. Once the functions have been loaded, they are called in the script, causing the first echo line to be printed and then the script to exit with a zero exit code. Notice that the second echo line is not printed.

It is good practice to declare all of your functions at the beginning of your shell script so that they are all in one central place and can be found easily later. If you realize halfway through a long shell script that you need a function and declare it there, and then use it afterward throughout the script, it will not cause any technical problem, but this practice makes for code that tends toward tangled spaghetti. Such code is hard to understand, hard to maintain, and more likely to contain bugs than the corresponding cleaner code.

It is instructive to note that if you try to declare a function within the declaration of another function, the second function will not be defined until the first function is called. It is better to avoid this headache and keep each function as an entirely separate unit.

Although you do not want to define functions inside of functions, it is not uncommon to call a function from within another function, as in the following example.

Try It Out: Calling Functions from within Other Functions

Put the following into a file called functioncall.sh:

#!/bin/bash

puerto_rico () {
  echo "Calling from Puerto Rico"
  haiti
}
haiti () {
  echo "Answering from Haiti"
}

puerto_rico

Notice that the haiti() function is being called before it is defined.

Now make the file executable:

$ chmod +x functioncall.sh

And finally, run the script:

$ ./functioncall.sh
"Calling from Puerto Rico"
"Answering from Haiti"

How It Works

Calling a function before it is defined seems contrary to the previous dictum regarding declaring functions before you use them. However, if you ran this script, you would see that it works. The puerto_rico function is called; it echoes Calling from Puerto Rico, and then it calls the second function, which simply echoes Answering from Haiti.

This script doesn't fail because of how bash works. Namely, it loads the two functions, but it does not execute any commands until it reaches the part of the script that actually calls the puerto_rico function. By the time it calls the function to actually execute it, it already has loaded into memory both the puerto_rico function and the haiti function.

Function Files

If you are writing a shell script that is long, I hope you will find yourself abstracting many aspects of your script into functions so that you may reuse your code rather than rewrite your code. Putting your functions at the beginning of your script is good practice; however, if the number of functions that you have defined becomes so large that your actual script doesn't start for pages and pages, you should consider putting all your functions into a function file.

A function file simply contains all of your functions, rather than putting them in your main script. To create a function file, remove your functions from your main script, and put them in a separate file. You must also add a line into your main script to load these functions; otherwise, they will not be known to the main script. To load these functions from your function file, you would replace the functions in your main script with the following line:

source function_file

The bash command source reads in and executes whatever file you specify; in this case, the file you are specifying is function_file. The name of this file is up to you. Because function_file contains only functions, bash simply loads all of these into memory and makes them available to the main script. (If you have commands outside of functions in this file, they are also run.) If you want to decrease the legibility of your shell script by taking a shortcut, you can substitute a period (.) for the bash command source; the period does the same thing as source but is much harder to notice. It is better to explicitly spell out that this is what you are doing by using source to keep your code readable.

When abstracting your functions into a function file, you should consider a number of things. One important consideration is where in the file system your function file is located. In the preceding example, no path was specified, so function_file has to exist in the directory where the main script is located. It must be located here every time this script is run. If you wish to put your functions in another location, you simply need to specify the path locating the function_file. This brings up another consideration: namely, that now you must manage multiple files associated with your one script. If these are worthy tradeoffs, then it makes sense to put your functions into a separate file; otherwise, it may be wise to leave them in the script itself.

Putting your functions into a function file makes these functions available to other scripts. You can write useful functions that you may want to reuse in the future, and instead of copying and pasting the functions from one script to another, you can simply reference the appropriate function files. Functions do not have to be associated with a particular script; they can be written to be completely atomic so that they are useful for as many scripts as possible.

Common Usage Errors

A common problem when invoking functions is including the parentheses when you shouldn't. You include the parentheses only when you are defining the function itself, not when you are using it. In the following Try It Out, you see what happens when you try to invoke a function using parentheses.

Try It Out: Incorrect Invocation

If you still have the diskusage function defined in your shell, try invoking it with parentheses:

$ diskusage ()
>

How It Works

It doesn't work! In fact, it gives you a bash continuation prompt; why is that? This will not work because the shell interprets it as a redefinition of the function diskusage. Typically, such an incorrect invocation results in a prompt similar to what you see in the preceding code. This is because the shell is interpreting what you thought was an invocation as a declaration of the function. This is no different from the multiline shell declaration example earlier on. If you try to invoke a function with parentheses within a script, you may get various different errors, usually of the form syntax error near unexpected token: and then the next line in your script. It can get confusing trying to figure out what went wrong, so try to remember that the parentheses are required for declaring a function only and must be omitted when using a function.

Undeclaring Functions

If you have defined a function, but you no longer want to have that function defined, you can undeclare the function using the unset command, as in the following example.

Try It Out: Undeclaring Functions

If you still have the diskusage function defined, you can unset it as follows:

$ declare -f diskusage
diskusage ()
{
    df -h
}
$ unset diskusage
$ declare -f diskusage
$ diskusage
bash: diskusage: command not found

How It Works

The first command shows that the diskusage function is still defined. Then you unset that function with the second command so it is not printed when you run the declare -f command the second time. The last command attempts to invoke the function, but the shell gives an error because the function is no longer defined. When a function is undefined, it is unknown to the shell as a valid command and cannot be used any longer.

Using Arguments with Functions

After functions have been declared, you effectively use them as if they were regular commands. Most regular Unix commands can take various arguments to change their behavior or to pass specific data to the command. In the same way that you can pass arguments to commands, you can use arguments when you execute functions. When you pass arguments to a function, the shell treats them in the same way that positional parameter arguments are treated when they are passed to commands or to shell scripts.

The individual arguments that are passed to functions are referenced as the numerical variables, $1, $2, and so on. The number of arguments is known as $#, and the set of variables available as $@. This is no different from how shell scripts themselves handle arguments.

Try It Out: Having Arguments

Put the following into a file called arguments.sh:

#!/bin/sh

arg ()
{
        echo "Number of arguments: $#"
        echo "Name of script: $0"
        echo "First argument: $1"
        echo "Second argument: $2"
        echo "Third argument: $3"
        echo "All the arguments: $@"
}

arg no yes maybe

Then make the script executable:

$ chmod +x arguments.sh

Then execute the argument.sh script:

$ ./arguments.sh
Number of arguments: 3
Name of script: ./arguments.sh
First argument: no
Second argument: yes
Third argument: maybe
All the arguments: no yes maybe

How It Works

The $# argument is expanded to print the number of arguments passed to the function. This does not include the $0 argument, or the $@ argument; the $0 argument is still set to the name of the script, not to the name of the function, as is apparent from the output; the first, second, and third arguments are all printed, and then the set of arguments is printed when $@ is echoed.

Using Return Codes with Functions

Every command you run in Unix returns an exit code, indicating the success or various failures that could occur. This exit code is not output on the screen after every command you type, but it is set into a shell variable, $?. Every time you run a command, this variable is set to the new exit code of that command. It is common in shell scripting to test this variable to see if something you ran succeeded the way you expect. Typically, if you run a command and it succeeds, an exit code of 0 is set into the $? variable; if the command doesn't succeed, the exit code will be set to a nonzero status. The different nonzero numbers that can be used for an exit code that fails depend solely on the program itself; generally, what they mean is documented in the man page of the command under the EXIT STATUS section of the man page. You can see the exit code at any point in the shell simply by running echo $?, which prints the exit code of the last command run, as you can see in the following Try It Out.

Try It Out: Shell Exit Codes

Run the following command in the shell:

$ nonexistant
bash: nonexistant: command not found

Then, before you type anything else, test the exit code:

$ echo $?
127

Compare the result with a valid command:

$ pwd
/tmp
$ echo $?
0

How It Works

The first command was a nonexistent Unix command, and bash gave an error indicating this. An exit code is also set, and in the first case, a nonexistent command exit code (127) is visible when you run echo $? immediately after running the command. The second example shows that when you run a valid command, the exit code is set to zero.

In the same way that commands in Unix return exit codes, shell scripts are often written to exit with different codes depending on the relative success or failure of the last command executed in the script, or if you explicitly specify an exit code with the exit command.

Within shell scripts themselves, functions are also designed to be able to return an exit code, although because the shell script isn't actually exiting when a function is finished, it is instead called a return code. Using return codes enables you to communicate outside of your function to the main script the relative success or failure of what happened within the function. In the same way that you can specify in your shell script exit with the exit code, you can specify return with a return code in a function. Analogous to exit codes, return codes are by convention a success if they are zero and a failure if they are nonzero. Additionally, in the same manner that exit codes work, if no return code is specified in a function, the success or failure of the last command in the function is returned by default.

Try It Out: Returning from Functions

Put the following into a text file called return.sh:

#!/bin/sh

implicit_good_return ()
{
        echo
}

explicit_good_return ()
{
        echo
        return
        this wont ever be executed
}

implicit_bad_return ()
{
        nosuchcommand
}

explicit_bad_return ()
{
        nosuchcommand
        return 127
}

implicit_good_return
echo "Return value from implicit_good_return function: $?"

explicit_good_return
echo "Return value from explicit_good_return function: $?"

implicit_bad_return
echo "Return value from implicit_bad_return_function: $?"

explicit_bad_return
echo "Return value from explicit_bad_return function: $?"

Then make it executable:

$ chmod +x return.sh

Finally, run it to see what it outputs:

$ ./return.sh
Return value from implicit_good_return function: 0

Return value from explicit_good_return function: 0
./return.sh: line 17: nosuchcommand: command not found
Return value from implicit_bad_return_function: 127
./return.sh: line 22: nosuchcommand: command not found
Return value from explicit_bad_return function: 127

How It Works

There are four functions defined at the top of the script, each one demonstrating different aspects of using return in functions. After the declaration of each function, they are invoked in turn, and their return codes are echoed to the screen.

The first function, implicit_good_return, simply runs the command echo when invoked (this is why there is the first empty line in the output). This function does not explicitly issue a return, but it is implicitly defined as the result code of the last command in the function that was executed. In this function's case, it is the result code of the echo command. This command executes successfully, and the $? exit code variable is set to zero, so the return value from this function is implicitly set to zero.

The second function explicitly issues a return call after it is finished executing its commands. It runs the echo command, as the first function did, and then it explicitly issues a return. The return has no numeric value provided in this example, so bash returns the value of the last command, in this case the result code of running echo. When the return is encountered, the function immediately exits and proceeds no further. It is for this reason the line after the return is never executed. When the return is encountered, the function is completed.

The third function deliberately executes a command that doesn't exist and implicitly returns, as the first example did, with no explicit return specified. Because of this, it returns the exit code of the last command run; in this case, the last command run fails because of error 127, so it returns this value. Error 127 is bash's error code for no such command.

In the final example, the same command as the third function is attempted, but in this case an explicit return is specified, this time with a result code, 127. This is a little redundant, because this result code is set already, but it shows that you can specify your own return value; it does not have to be the default shell built-in error codes. In fact, you may wish to return values from functions in situations where there is no error, but you want to know which way a function went.

Variable Scope: Think Globally, Act Locally

Functions are often written to perform work and produce a result. That result is something that you usually want to use in your shell script, so it needs to be available outside the context of the function where it is set. In many programming languages, variables in functions and subroutines are available only within the functions themselves. These variables are said to have local scope because they are local only to the function. However, in bash shell scripts, variables are available everywhere in the script; hence, they are referred to as having global scope and are called global variables.

Programmers who fancy themselves to have style will recognize global variables as the path that leads to sloppy code. Throwing the scope wide open allows for mistakes and carelessness, because there are no formal restrictions keeping you from doing something that obfuscates or redefines a variable without your knowing it. Programs are generally easier to read, understand, and hence maintain when global variables are restricted. If you can read and modify a variable anywhere in your script, it becomes difficult to remember every place that you have used it and hard to reason through all the potential uses and changes it might undergo. It is easy to end up with unexpected results if you are not careful. You may even forget that you used a variable in some function and then use it again, thinking it has never been used.

However, you can still write good, clean code by being careful. Keeping your variable names unique to avoid namespace pollution is a good first step. In the same way that your function names should be named clearly, so should your variables. It is bad practice to use variables such as a or b; instead use something descriptive so you aren't likely to use it again unless you are using it for the exact purpose it was meant for.

Try It Out: Variable Scope

The following shell script, called chaos.sh, provides a good illustration of how variable scope works:

#!/bin/bash

chaos () {
 if [ "$1" = "begin" ]
 then
         butterfly_wings="flapping"
         location="Brazil"
         return 0
 else
         return 1
 fi
}

theorize () {

 chaos_result=$?
 if [ "$butterfly_wings" = "flapping" ]
 then
         tornado="Texas"
 fi

 if [ $chaos_result -eq 0 ]
 then
         echo -n "If a butterfly flaps its wings in $location, a tornado"
         echo " is caused in $tornado."
 else
         echo -n "When a butterfly rests at night in $location, the"
         echo " stars are big and bright in $tornado."
 fi
}

# Begin the chaos
chaos yes

# What happens when we instigate chaos?
theorize

# Stop the madness
chaos no

# What happens when there is no chaos?
theorize

How It Works

This script illustrates not only how variables are available in a global scope but also bad scripting practice involving global variables and, as a bonus, a mixed metaphor. Let's go over it from the beginning to fully understand what is going on.

In the beginning, the function chaos is defined. It tests the first positional argument to see if it is set to yes; if it is, the function sets the butterfly wings flapping, sets the location to Brazil, and finally returns a zero. If the first positional argument is not set to yes, then the function returns a 1 and sets no variables.

The second function is then defined. This function looks at the result returned from the first function. (This implicitly makes the theorize function useful only if it is called after the chaos function; this can be improved so that if a mistake is made and you theorize before calling chaos, you will have an expected result, preferably an error.) It then looks to see if the butterfly wings are flapping, and if they are, it starts up a tornado in Texas. Here, you see an example of global variables: The value of the butterfly_wings variable in the chaos function is available in this theorize function. If the variable scope were limited, you would not have this variable available. The next thing that happens in the function is that the chaos_result variable is tested. If it equals 0, it prints out the first message; otherwise, it prints out the second message.

After the two functions have been defined, they are called at the end of the script, first by passing the variable yes to the chaos function and then calling the theorize function to see what happens when chaos has been passed the yes variable. It then calls the chaos function again with no and then theorizes what happens when there is no chaos.

If you run this script, it prints the first echo line, followed by the second echo line. This seems to be the correct behavior. However, because of sloppy programming, I am using global variables in ways that I think work, and they appear to work in this way, but you will soon discover that this approach has problems with some cases. If you change the script slightly so that chaos is called with the no variable first and with the yes variable second, and then run the script, unplanned results occur:

When a butterfly rests at night in, the stars are are big and bright in .
If a butterfly flaps its wings in Brazil, a tornado is caused in Texas.

Some locations are missing in this output. You might argue that you would never call the functions in this order, but trying to remember this is not the solution; the code should be written so you don't have to remember this.

Using the global variable $tornado sloppily in the output to stand for a location is not the right way to do things (nor is theorizing like this). When you typed the line in the script that said:

echo " stars are big and bright in $tornado"

it did seem odd that stars would be big and bright in a tornado, didn't it? It sometimes requires more code to be less sloppy, but lines of code should be saved by using functions, rather than by cutting corners.

Understanding Recursion

Recursion has been humorously defined as follows: "When a function calls itself, either directly or indirectly. If this isn't clear, refer to the definition of recursion." Recursion can be very powerful when used in functions to get work done in a beautifully simple manner. You have seen how it is possible to call a function from within another function. To perform recursion, you simply have a function call itself, rather than calling another function. Variables in functions need to change every time they are recursed; otherwise, you end up with an infinite loop scenario, so your program, infinitely recursing over itself without ever finishing, will never end. The beauty of recursion is to loop just the right number of times and not infinitely. Recursion allows you to loop as many times as necessary without having to define the number of times. The following Try It Out shows you how to perform simple recursion.

Try It Out: Recursion

Type the following script into a file called recursion.sh:

#!/bin/bash

countdown() {

      if [ $1 -lt 0 ]
      then
        echo "Blast off!"
        return 0
      fi

      current_value=$1
      echo $current_value
      current_value=`expr $1 - 1`
      countdown $current_value
}

countdown 10

if [ $? -eq 0 ]
then
 echo "We have lift-off!"
 exit 0
fi

Make the script executable:

$ chmod +x recursion.sh

Then run it:

$ ./recursion.sh
10
9
8
7
6
5
4
3
2
1
0
"Blast off!"
"We have lift-off!"

How It Works

This shell script contains only one function, countdown, and when it is called with a numerical argument, it counts down from that number to 0. This works through function recursion.

The function first tests to see if the positional argument $1 is less than 0. If it is, the rocket blasts off, and the function returns 0. This is an important element of a recursive function; it stops an endless loop from happening. If you would like to see what an endless loop looks like, remove this if block, and run the script again. You will need to interrupt the endless loop with Ctrl-C, otherwise, it will run forever.

In the first pass through this function, the positional argument $1 is set to the number 10. The if block tests and finds that 10 is not less than 0, so it does not exit and instead continues with the rest of the code block.

The next step in the process is for the value of the positional argument $1 to be put into the variable current _value; then this value is echoed to the screen. Then the current_value variable has 1 subtracted from it, and the result of this subtraction is placed into the value itself.

The next and last command in this code block is to call the function itself, passing the variable current_value to the function. This is where the recursion happens. Because prior to this, the current_value variable had 1 subtracted from it, the second iteration of the function will be called with the number 9, rather than 10 again.

This recursion happens until the test at the beginning of the function has found that the value of $1 is less than 0. When it is, it launches the rocket and then returns a success value. The script continues by testing the result of the countdown function, and if it finds that the result was good, it announces to the world, We have lift-off!

This example shows that recursion requires two things. The first is that something must change in the function each time it is iterated over; otherwise, it will do the same thing over and over until eternity. The thing that is changed each time can be a variable, an array, a string, or the like. The second thing that must be in place to keep recursion from happening infinitely is that there must be a test of the thing that changes in order to determine when the recursion should end.

Summary

Functions are an essential aspect of shell scripting. They allow you to organize your scripts into modular elements that are easier to maintain and to enhance. Although you do not need to use functions, they often help you save time and typing by defining something once and using it over and over again. Because the syntax for defining functions is very simple, you are encouraged to use them whenever you can. Functions can be understood, both conceptually as well as syntactically, as shell scripts within shell scripts. This concept is extended even more powerfully when you use functions recursively.

In this chapter, you learned:

  • What functions are and how they are useful in saving time and typing

  • What makes a function: the function name and the associated code block

  • How to declare functions in a single line, on multiple lines, in shell scripts, and in separate function files

  • How to show what a function is defined as, how to test if a function is defined, and how to undefine a function

  • Some common function declaration missteps and how to avoid them

  • How numerical positional variables can be used as function arguments as well as the standard shell arguments

  • How to define and use exit status and return values in functions

  • Variable scope, global variables, and problematic aspects to global variables

  • And finally, how to use recursion in functions to perform powerful operations

Tracking down difficult bugs in your scripts can sometimes be the most time-consuming process of shell scripting, especially when the error messages you get are not very helpful. The next chapter covers techniques for debugging your shell scripts that will make this process easier.

Exercises

  1. Experiment with defining functions: See what happens when you fail to include a semicolon on the command line between commands or when you forget to close the function with the final curly brace. Become familiar with what happens when functions are defined incorrectly so you will know how to debug them when you use them practically.

  2. What is wrong with creating a function called ls that replaces the existing command with a shortcut to your favorite switches to the ls command?

  3. What is the difference between defining a shell function and setting a shell alias?

  4. Write an alarm clock script that sleeps for a set number of seconds and then beeps repeatedly after that time has elapsed.

  5. Use a recursive function to print each argument passed to the function, regardless of how many arguments are passed. You are allowed to echo only the first positional argument (echo $1).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.135.247.68