More bash programming fundamentals<\/p>\n
Let’s start with a brief tip on handling command-line arguments, and then
\nlook at bash’s basic programming constructs.<\/p>\n
In the sample program in the introductory article<\/a>, we used the environment variable “$1”, #!\/usr\/bin\/env bash<\/p>\n echo name of script is $0 The example is self explanatory except for three small details. First, “$0” Sometimes, it’s helpful to refer to all<\/em> command-line arguments at If you’ve programmed in a procedural language like C, Pascal, Python, or If you’ve ever programmed any file-related code in C, you know that it The following table lists the most frequently used bash comparison if [ -z “$myvar” ] Note: You must separate the square brackets from other Sometimes, there are several different ways that a particular comparison if [ “$myvar” -eq 3 ] if [ “$myvar” = “3” ] If $myvar is an integer, these two comparisons do If $myvar is not an integer,<\/p>\n then the first comparison will fail with an error.<\/p>\n Most of the time, while you can omit the use of double quotes surrounding if [ $myvar = “foo bar oni” ] In the above example, if myvar equals “foo”, the code will work as expected [: too many arguments<\/p>\n In this case, the spaces in “$myvar” (which equals “foo bar oni”) end up [ foo bar oni = “foo bar oni” ]<\/p>\n Similarly, if myvar is the empty string, you will have too few arguments [: =: unary operator expected<\/p>\n Because the environment variable wasn’t placed inside double quotes, bash if [ “$myvar” = “foo bar oni” ] If you want your environment variables to be expanded, you must enclose them The above code will work as expected and will not create any unpleasant surprises.<\/p>\n OK, we’ve covered conditionals, now it’s time to explore bash looping #!\/usr\/bin\/env bash<\/p>\n for x in one two three four output: What exactly happened? The “for x” part of our “for” loop defined a new #!\/usr\/bin\/env bash<\/p>\n for myfile in \/etc\/r* output:<\/p>\n \/etc\/rc.d (dir) The above code looped over each file in \/etc that began with an “r”. To do We can also use multiple wildcards and even environment variables in the for x in \/etc\/r??? \/var\/lo* \/home\/drobbins\/mystuff\/* \/tmp\/$\/* Bash will perform wildcard and variable expansion in all the right places, While all of our wildcard expansion examples have used absolute<\/em> for x in ..\/* mystuff\/* In the above example, bash performs wildcard expansion relative to the for x in \/var\/log\/* Of course, it’s often handy to perform loops that operate on a script’s #!\/usr\/bin\/env bash<\/p>\n for thing in “$@” output:<\/p>\n $ allargs hello there you silly Before looking at a second type of looping construct, it’s a good idea to $ echo $(( 100 \/ 3 )) Now that you’re familiar performing mathematical operations, it’s time to A “while” statement will execute as long as a particular condition is while [ condition ] “While” statements are typically used to loop a certain number of times, as myvar=0 You can see the use of arithmetic expansion to eventually cause the “Until” statements provide the inverse functionality of “while” statements: myvar=0 Case statements are another conditional construct that comes in handy. case “$” in Above, bash first expands “$”. In the code, “$x” is the name of a In bash, you can even define functions, similar to those in other tarview() { The above code could have been written using a “case” statement. Above, we define a function called “tarview” that accepts one argument, a $ tarview shorten.tar.gz Don’t forget that functions, like the one above, can be placed As you can see, arguments can be referenced inside the function definition Often, you’ll need to create environment variables inside a function. While true in C, this isn’t true in bash. In bash, whenever you create an #!\/usr\/bin\/env bash<\/p>\n myvar=”hello”<\/p>\n myfunc() {<\/p>\n myvar=”one two three” myfunc<\/p>\n echo $myvar $x<\/p>\n When this script is run, it produces the output “one two three three”, In this simple example, the bug is easy to spot and to compensate for by #!\/usr\/bin\/env bash<\/p>\n myvar=”hello”<\/p>\n myfunc() { myfunc<\/p>\n echo $myvar $x<\/p>\n This function will produce the output “hello” — the global “$myvar” Now that we’ve covered the most essential bash functionality, it’s time to Subscribe me to comment notifications<\/p>\n
\nwhich referred to the first command-line argument. Similarly, you can use
\n“$2”, “$3”, etc. to refer to the second and third arguments passed to your
\nscript. Here’s an example:<\/p>\n
\necho first argument is $1
\necho second argument is $2
\necho seventeenth argument is $
\necho number of arguments is $#<\/p>\n
\nwill expand to the name of the script, as called from the command line,
\nsecond, for arguments 10 and above, you need to enclose the whole argument
\nnumber in curly braces, and third, “$#” will expand to the number of
\narguments passed to the script. Play around with the above script, passing
\ndifferent kinds of command-line arguments to get the hang of how it
\nworks.<\/p>\n
\nonce. For this purpose, bash features the “$@” variable, which expands to
\nall command-line parameters separated by spaces. We’ll see an example of
\nits use when we take a look at “for” loops, a bit later in this
\narticle.<\/p>\nBash programming
\nconstructs<\/h2>\n
\nPerl, then you’re familiar with standard programming constructs like “if”
\nstatements, “for” loops, and the like. Bash has its own versions of most
\nof these standard constructs. In the next several sections, I will
\nintroduce several bash constructs and demonstrate the differences between
\nthese constructs and others you are already familiar with from other
\nprogramming languages. If you haven’t programmed much before, don’t worry.
\nI include enough information and examples so that you can follow the
\ntext.<\/p>\nConditional love<\/h2>\n
\nrequires a significant amount of effort to see if a particular file is
\nnewer than another. That’s because C doesn’t have any built-in syntax for
\nperforming such a comparison; instead, two stat() calls and two stat
\nstructures must be used to perform the comparison by hand. In contrast,
\nbash has standard file comparison operators built in, so determining if
\n“\/tmp\/myfile is readable” is as easy as checking to see if “$myvar is
\ngreater than 4”.<\/p>\n
\noperators. You’ll also find an example of how to use every option
\ncorrectly. The example is meant to be placed immediately after the “if”.
\nFor example:<\/p>\n
\nthen
\necho “myvar is not defined”
\nfi<\/p>\n
\ntext by a space.<\/p>\nCommon Bash comparisons<\/h5>\n
\n\n
\n \nOperator<\/th>\n Meaning<\/th>\n Example<\/th>\n<\/tr>\n<\/thead>\n \n -z<\/td>\n Zero-length string<\/td>\n [ -z “$myvar” ]<\/td>\n<\/tr>\n \n -n<\/td>\n Non-zero-length string<\/td>\n [ -n “$myvar” ]<\/td>\n<\/tr>\n \n =<\/td>\n String equality<\/td>\n [ “abc” = “$myvar” ]<\/td>\n<\/tr>\n \n !=<\/td>\n String inequality<\/td>\n [ “abc” != “$myvar” ]<\/td>\n<\/tr>\n \n -eq<\/td>\n Numeric equality<\/td>\n [ 3 -eq “$myinteger” ]<\/td>\n<\/tr>\n \n -ne<\/td>\n Numeric inequality<\/td>\n [ 3 -ne “$myinteger” ]<\/td>\n<\/tr>\n \n -lt<\/td>\n Numeric strict less than<\/td>\n [ 3 -lt “$myinteger” ]<\/td>\n<\/tr>\n \n -le<\/td>\n Numeric less than or equals<\/td>\n [ 3 -le “$myinteger” ]<\/td>\n<\/tr>\n \n -gt<\/td>\n Numeric strict greater than<\/td>\n [ 3 -gt “$myinteger” ]<\/td>\n<\/tr>\n \n -ge<\/td>\n Numeric greater than or equals<\/td>\n [ 3 -ge “$myinteger” ]<\/td>\n<\/tr>\n \n -f<\/td>\n Exists and is regular file<\/td>\n [ -f “$myfile” ]<\/td>\n<\/tr>\n \n -d<\/td>\n Exists and is directory<\/td>\n [ -d “$mydir” ]<\/td>\n<\/tr>\n \n -nt<\/td>\n First file is newer than second one<\/td>\n [ “$myfile” -nt ~\/.bashrc ]<\/td>\n<\/tr>\n \n -ot<\/td>\n First file is older than second one<\/td>\n [ “$myfile” -ot ~\/.bashrc ]<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\ncan be made. For example, the following two snippets of code function
\nidentically:<\/p>\n
\nthen
\necho “myvar equals 3”
\nfi<\/p>\n
\nthen
\necho “myvar equals 3”
\nfi<\/p>\n
\nexactly the same thing, but the first uses arithmetic comparison
\noperators, while the second uses string comparison operators.<\/p>\nString comparison caveats<\/h2>\n
\nstrings and string variables, it’s not a good idea. Why? Because your code
\nwill work perfectly, unless an environment variable happens to have a
\nspace or a tab in it, in which case bash will get confused. Here’s an
\nexample of a fouled-up comparison:<\/p>\n
\nthen
\necho “yes”
\nfi<\/p>\n
\nand not print anything. However, if myvar equals “foo bar oni”, the code
\nwill fail with the following error:<\/p>\n
\nconfusing bash. After bash expands “$myvar”, it ends up with the following
\ncomparison:<\/p>\n
\nand the code will fail with the following error:<\/p>\n
\nthinks that you stuffed too many (or too few) arguments in-between the
\nsquare brackets. You can easily eliminate this problem by surrounding the
\nstring arguments with double-quotes. Remember, if you get into the habit
\nof surrounding all string arguments and environment variables with
\ndouble-quotes, you’ll eliminate many similar programming errors. Here’s
\nhow the “foo bar oni” comparison should<\/em> have been written:<\/p>\n
\nthen
\necho “yes”
\nfi<\/p>\nMore quoting specifics<\/h5>\n
\nin double quotes<\/em>, rather than single quotes. Single quotes
\ndisable<\/em> variable (as well as history) expansion.<\/p>\nLooping constructs: “for”<\/h2>\n
\nconstructs. We’ll start with the standard “for” loop. Here’s a basic
\nexample:<\/p>\n
\ndo
\necho number $x
\ndone<\/p>\n
\nnumber one
\nnumber two
\nnumber three
\nnumber four<\/p>\n
\nenvironment variable (also called a loop control variable) called “$x”,
\nwhich was successively set to the values “one”, “two”, “three”, and
\n“four”. After each assignment, the body of the loop (the code between the
\n“do” … “done”) was executed once. In the body, we referred to the loop
\ncontrol variable “$x” using standard variable expansion syntax, like any
\nother environment variable. Also notice that “for” loops always accept
\nsome kind of word list after the “in” statement. In this case we specified
\nfour English words, but the word list can also refer to file(s) on disk or
\neven file wildcards. Look at the following example, which demonstrates how
\nto use standard shell wildcards:<\/p>\n
\ndo
\nif [ -d “$myfile” ]
\nthen
\necho “$myfile (dir)”
\nelse
\necho “$myfile”
\nfi
\ndone<\/p>\n
\n\/etc\/resolv.conf
\n\/etc\/resolv.conf~
\n\/etc\/rpc<\/p>\n
\nthis, bash first took our wildcard \/etc\/r* and expanded it, replacing it
\nwith the string \/etc\/rc.d \/etc\/resolv.conf \/etc\/resolv.conf~ \/etc\/rpc
\nbefore executing the loop. Once inside the loop, the “-d” conditional
\noperator was used to perform two different actions, depending on whether
\nmyfile was a directory or not. If it was, a ” (dir)” was appended to the
\noutput line.<\/p>\n
\nword list:<\/p>\n
\ndo
\ncp $x \/mnt\/mydir
\ndone<\/p>\n
\nand potentially create a very long word list.<\/p>\n
\npaths, you can also use relative paths, as follows:<\/p>\n
\ndo
\necho $x is a silly file
\ndone<\/p>\n
\ncurrent working directory, just like when you use relative paths on the
\ncommand line. Play around with wildcard expansion a bit. You’ll notice
\nthat if you use absolute paths in your wildcard, bash will expand the
\nwildcard to a list of absolute paths. Otherwise, bash will use relative
\npaths in the subsequent word list. If you simply refer to files in the
\ncurrent working directory (for example, if you type “for x in *”), the
\nresultant list of files will not be prefixed with any path information.
\nRemember that preceding path information can be stripped using the
\n“basename” executable, as follows:<\/p>\n
\ndo
\necho `basename $x` is a file living in \/var\/log
\ndone<\/p>\n
\ncommand-line arguments. Here’s an example of how to use the “$@” variable,
\nintroduced at the beginning of this article:<\/p>\n
\ndo
\necho you typed $.
\ndone<\/p>\n
\nyou typed hello.
\nyou typed there.
\nyou typed you.
\nyou typed silly.<\/p>\nShell arithmetic<\/h2>\n
\nbecome familiar with performing shell arithmetic. Yes, it’s true: You can
\nperform simple integer math using shell constructs. Simply enclose the
\nparticular arithmetic expression between a “$((” and a “))”, and bash will
\nevaluate the expression. Here are some examples:<\/p>\n
\n33
\n$ myvar=”56″
\n$ echo $(( $myvar + 12 ))
\n68
\n$ echo $(( $myvar – $myvar ))
\n0
\n$ myvar=$(( $myvar + 1 ))
\n$ echo $myvar
\n57<\/p>\n
\nintroduce two other bash looping constructs, “while” and “until”.<\/p>\nMore looping constructs: “while”
\nand “until”<\/h2>\n
\ntrue, and has the following format:<\/p>\n
\ndo
\nstatements
\ndone<\/p>\n
\nin the following example, which will loop exactly 10 times:<\/p>\n
\nwhile [ $myvar -ne 10 ]
\ndo
\necho $myvar
\nmyvar=$(( $myvar + 1 ))
\ndone<\/p>\n
\ncondition to be false, and the loop to terminate.<\/p>\n
\nThey repeat as long as a particular condition is false<\/em>. Here’s an
\n“until” loop that functions identically to the previous “while” loop:<\/p>\n
\nuntil [ $myvar -eq 10 ]
\ndo
\necho $myvar
\nmyvar=$(( $myvar + 1 ))
\ndone<\/p>\nCase statements<\/h2>\n
\nHere’s an example snippet:<\/p>\n
\ngz)
\ngzunpack $\/$
\n;;
\nbz2)
\nbz2unpack $\/$
\n;;
\n*)
\necho “Archive format not recognized.”
\nexit
\n;;
\nesac<\/p>\n
\nfile, and “$” has the effect of stripping all text except that
\nfollowing the last period in the filename. Then, bash compares the
\nresultant string against the values listed to the left of the “)”s. In
\nthis case, “$” gets compared against “gz”, then “bz2” and finally
\n“*”. If “$” matches any of these strings or patterns, the lines
\nimmediately following the “)” are executed, up until the “;;”, at which
\npoint bash continues executing lines after the terminating “esac”. If no
\npatterns or strings are matched, no lines of code are executed; however,
\nin this particular code snippet, at least one block of code will execute,
\nbecause the “*” pattern will catch everything that didn’t match “gz” or
\n“bz2”.<\/p>\nFunctions and namespaces<\/h2>\n
\nprocedural languages like Pascal and C. In bash, functions can even accept
\narguments, using a system very similar to the way scripts accept
\ncommand-line arguments. Let’s take a look at a sample function definition
\nand then proceed from there:<\/p>\n
\necho -n “Displaying contents of $1 ”
\nif [ $ = tar ]
\nthen
\necho “(uncompressed tar)”
\ntar tvf $1
\nelif [ $ = gz ]
\nthen
\necho “(gzip-compressed tar)”
\ntar tzvf $1
\nelif [ $ = bz2 ]
\nthen
\necho “(bzip2-compressed tar)”
\ncat $1 | bzip2 -d | tar tvf –
\nfi
\n}<\/p>\nAnother case<\/h5>\n
\nCan you figure out how?<\/p>\n
\ntarball of some kind. When the function is executed, it identifies what
\ntype of tarball the argument is (either uncompressed, gzip-compressed, or
\nbzip2-compressed), prints out a one-line informative message, and then
\ndisplays the contents of the tarball. This is how the above function
\nshould be called (whether from a script or from the command line, after it
\nhas been typed in, pasted in, or sourced):<\/p>\n
\nDisplaying contents of shorten.tar.gz (gzip-compressed tar)
\ndrwxr-xr-x ajr\/abbot 0 1999-02-27 16:17 shorten-2.3a\/
\n-rw-r–r– ajr\/abbot 1143 1997-09-04 04:06 shorten-2.3a\/Makefile
\n-rw-r–r– ajr\/abbot 1199 1996-02-04 12:24 shorten-2.3a\/INSTALL
\n-rw-r–r– ajr\/abbot 839 1996-05-29 00:19 shorten-2.3a\/LICENSE
\n….<\/p>\nUse ’em interactively<\/h5>\n
\nin your ~\/.bashrc or ~\/.bash_profile so that they are available
\nfor use whenever you are in bash.<\/p>\n
\nby using the same mechanism used to reference command-line arguments. In
\naddition, the “$#” macro will be expanded to contain the number of
\narguments. The only thing that may not work completely as expected is the
\nvariable “$0”, which will either expand to the string “bash” (if you run
\nthe function from the shell, interactively) or to the name of the script
\nthe function is called from.<\/p>\nNamespace<\/h2>\n
\nWhile possible, there’s a technicality you should know about. In most
\ncompiled languages (such as C), when you create a variable inside a
\nfunction, it’s placed in a separate local namespace. So, if you define a
\nfunction in C called myfunction, and in it define a variable called “x”,
\nany global (outside the function) variable called “x” will not be affected
\nby it, eliminating side effects.<\/p>\n
\nenvironment variable inside a function, it’s added to the global<\/em>
\nnamespace. This means that it will overwrite any global variable outside
\nthe function, and will continue to exist even after the function
\nexits:<\/p>\n
\nfor x in $myvar
\ndo
\necho $x
\ndone
\n}<\/p>\n
\nshowing how “$myvar” defined in the function clobbered the global variable
\n“$myvar”, and how the loop control variable “$x” continued to exist even
\nafter the function exited (and also would have clobbered any global “$x”,
\nif one were defined).<\/p>\n
\nusing alternate variable names. However, this isn’t the right approach;
\nthe best way to solve this problem is to prevent the possibility of
\nclobbering global variables in the first place, by using the “local”
\ncommand. When we use “local” to create variables inside a function, they
\nwill be kept in the local<\/em> namespace and not clobber any global
\nvariables. Here’s how to implement the above code so that no global
\nvariables are overwritten:<\/p>\n
\nlocal x
\nlocal myvar=”one two three”
\nfor x in $myvar
\ndo
\necho $x
\ndone
\n}<\/p>\n
\ndoesn’t get overwritten, and “$x” doesn’t continue to exist outside of
\nmyfunc. In the first line of the function, we create x, a local variable
\nthat is used later, while in the second example (local myvar=”one two
\nthree””) we create a local myvar and<\/em> assign it a value. The first
\nform is handy for keeping loop control variables local, since we’re not
\nallowed to say “for local x in $myvar”. This function doesn’t clobber any
\nglobal variables, and you are encouraged to design all your functions this
\nway. The only time you should not<\/em> use “local” is when you
\nexplicitly want to modify a global variable.<\/p>\nWrapping it up<\/h2>\n
\nlook at how to develop an entire application based in bash. In my next
\ninstallment, we’ll do just that. See you then!<\/p>\nDownloadable resources<\/h4>\n
\n
\n
\nhome page<\/a>.<\/li>\n<\/ul>\n