Pricing Table Particle

Quickly drive clicks-and-mortar catalysts for change
  • Basic
  • Standard Compliant Channels
  • $50
  • Completely synergize resource taxing relationships via premier market
  • 1 GB of space
  • Support at $25/hour
  • Sign Up
  • Premium
  • Standard Compliant Channels
  • $100
  • Completely synergize resource taxing relationships via premier market
  • 10 GB of space
  • Support at $15/hour
  • Sign Up
  • Platinum
  • Standard Compliant Channels
  • $250
  • Completely synergize resource taxing relationships via premier market
  • 30 GB of space
  • Support at $5/hour
  • Sign Up

Passing Dynamic Arguments to Bash Scripts

It is possible to pass arguments to a bash script when it is called from the command line. This is the technique to use when you need to have your script carry out different actions each time it runs dependent on the input and the context. This is done by passing selected parameters to the file on the command line and these parameters are called arguments.

Lets look at an example, you may have a script called "" that performs a particular operation on an RRD file, such as extracting the data. If you want to be able to use that script on many RRD files in many different user directories, it is best to pass the file path as an argument, so that you can use the same script for all the files to be processed.

For instance, if the username to be graphed is "ASmith", you would enter the following command line:

sh ASmith

Any arguments passed to the file are accessed internally within the script by using variables $1, $2, etc. This denotes that $1 references the first argument, $2 the second, and so on. Lets illustrate this in an example:


rrdgraph $ASmith

in order to ensure readability, assign your variables with descriptive names and then call the graphing utility (rrdgraph) on this variable ($ASmith).

If the number of arguments is likely to change then you can use the "$@" variable, which creates an array of all the input parameters. This technique enables the use of a for-loop to iteratively process each one, as illustrated in the following example:

for $user in "$@"


 rrdgraph $user


Here is an example of how to call this script with arguments from the command line:

sh user1 user2 user3


What if your arguments have spaces?

If any of your arguments have spaces, you need to enclose the full argument in single quotes.

For example:

Let say you have a script that pulls information from your database using specific parameters, such as "uname", "todays date", and "description", and then produces a report in an "output format" of the users choice. Now you want to write your script so that you can pass in these parameters when the script is called. It might look like this: 

extractreport -u jsmith -d notebooks -td 10-20-2011 -of pdf

Bash enables this functionality with the "getopts" function. For the above example, you could use getopts as follows:

while getopts u:d:td:of: option


 case "${option}"


 u) USER=${OPTARG};;

 d) DATE=${OPTARG};;





This is a while-loop that uses the "getopts" function and a so-called "optstring", in this case "u:d:p:f:", to iterate through the arguments. The while-loop walks through the optstring, which contains the flags that can be used to pass arguments, and assigns the argument value provided for that flag to the variable "option". The case-statement then assigns the value of the variable "option" to a global variable that can used after all the arguments have been read.

The colons in the optstring mean that values are required for the corresponding flags. In the above example all flags are followed by a colon: "u:d:p:f:".

sh 'songlist 1' 'songlist 2' 'songlist 3'

Frequently a script is written such that the user can pass in arguments in any order using flags. With the flags method, you can also make some of the arguments optional.

This means, all flags need a value. If, for example, the "d" and "f" flags were not expected to have a value, the optstring would be "u:dp:f".

A colon at the beginning of the optstring, for example ":u:d:p:f:", has a completely different meaning. It allows you to handle flags that are not represented in the optstring. In that case the value of the "option" variable is set to "?" and the value of "OPTARG" is set to the unexpected flag. The allows you to display a suitable error message informing the user of the mistake.

Arguments that are not preceded by a flag are ignored by getopts. If flags specified in the optstring are not provided when the script is called, nothing happens, unless you specially handle this case in your code.

Any arguments not handled by getops can still be captured with the regular $1, $2, etc. variables.

Continue reading
30 Hits