May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Bash Variables


Bash Recommended  Links BASH Debugging Bash expressions Bash Control Structures


Arithmetic Expressions in BASH String Operations in Shell Process Substitution in Shell Brace Expansion Command history reuse Advanced filesystem navigation Command completion
 IFS Dotfiles Shell Prompts Bash tips Annotated List of Bash Enhancements Humor Etc


By default, bash variables are untyped created at the moment they are first referenced, and can be used both for arithmetic operations and string parsing. There is opportunity to declare integer variables, but not string variables. They can be global (external), local to the shell instance, local to the function and built-in. 

Access can be read-write or read-only.

Variables in  bash can be classified into two groups:

Use the set  command to see the value of all variables and function definitions in the current shell at a given point of execution of the script.

Use the env command to see only those variables that have been exported and would be available to a subshell.


Export of variables

To make the value of a shell variable available not just to the shell, but to programs invoked by using the shell (for example stages of the pipe), you must export the shell variable. To do so, use the export  command, which has the form:

export variable

where variable specifies the name of the variable to be exported. A shorthand form of the command lets you assign a value to a shell variable and export the variable in a single command:

export variable=value

Predefined system variables

There are many system variables that are defined in bash. All of them are exported variables.

They are set by operating system or during bash initialization. Among them:

Environment variable Use
BASH_VERSION The version of Bash in current session
HOME The home directory of the current user (absolute path)
HOSTNAME The name of the host
LANG The locale used to manage the data
PATH The search path for the shell
LD_LIBRARY_PATH Same for libraries
PS1 The prompt configuration
PWD The path to the current directory
USER The name of the current user (includes changes caused su command)
LOGNAME Login name of the user for the session

For us two variables are of primary important: PATH and LD_LIBRARY_PATH. Both define set of directories that can be accesses by bash when loading the program (PATH) or loading a library (LD_LIBRARY_PATH).  In modern cluster environment those variables are usually set for each application using modules files.

Another important directory is HOME. It is usually set to /home/UserID.  Along with /home directory, which contains user directories,  most Linux distributions include the following directories:

You can see a list of system variables in you environment by issuing the env command. Usually, the command produces more than a single screen of output. So, you can use a pipe redirector and the more  command to view the output one screen at a time:

env | more

Press the Space bar to see each successive page of output: there are over 50 variables in environment. You'll probably see several of the shell variables described below:

You can use the value of a shell variable in a command by preceding the name of the shell variable by a dollar sign ($). To avoid confusion with surrounding text, you can enclose the name of the shell variable within curly braces ({}); 

For example, you can change the current working directory to your home directory by issuing the command:

cd $HOME

which can be shortened to


Shell variables are widely used within shell scripts, because they provide a convenient way of transferring values from one command to another. Programs can obtain the value of a shell variable and use the value to modify their operation, in much the same way they use the value of command-line arguments.

The easiest way to see the value of a shell variable is to specify the variable as the argument of the echo  command. For example, to see the value of the PATH shell variable, issue the command:

echo $PATH

PATH Variable

There are multiple system variable in shell, the variables that are set by the system.

For example, PATH variable.  It is populated by OS when you bash session is initialized. Of course you cal also set it yourself, for example: 


assigns  to the PATH the value


PATH holds a series of paths known collectively as the search path. Whenever you issue an external command, the shell searches paths that comprise the search path, seeking the program file that corresponds to the command. The startup scripts establish the initial value of the PATH shell variable, but you can modify its value to include any desired series of paths. You must use a colon (:) to separate each path of the search path.

For example, suppose that PATH has the following value:


You can add a new search directory, say /opt/bin, with the following command:


Now, the shell will look for external programs in /opt/bin/ as well as the default directories. However, it will look there last. If you prefer to check /opt/bin first, issue the following command instead:


The which command helps you work with the PATH shell variable. It checks the search path for the file specified as its argument and prints the name of the matching path, if any. For example, suppose you want to know where the program file for the wc  command resides. Issuing the command:

which wc

will tell you that the program file is /usr/bin/wc, or whatever other path is correct for your system.

LD_LIBRARY_PATH system variable

The LD_LIBRARY_PATH environment variable contains a colon separated list of paths that the linker uses to resolve library dependencies of ELF executables at run-time. These paths will be given priority over the standard library paths /lib and /usr/lib. The standard paths will still be searched, but only after the list of paths in LD_LIBRARY_PATH has been exhausted.

The best way to use LD_LIBRARY_PATH is to set it via Environment Modules immediately before executing the program. This way you can keep the new LD_LIBRARY_PATH isolated from the rest of your system.

module load myprogram

See Wikipedia for a good description of environmental modules package

In general it is not a good practice to have LD_LIBRARY_PATH permanently set in your environment.  that's why environment modules package was created. Setting it permanently in .bashrc could lead to unintended side effects as programs can link to unintended libraries producing strange results or unexpectedly crashing with new programs after you switch to them and forget to current your .bashrc.  There is also the possibility introducing potential security threats.

All those warnings aside, if you do not have environment module for your application you can set it permanently by placing a line similar to this in your .bashrc in your home directory.

The most common case for setting LD_LIBRARY_PATH is when you have an application that requires dynamic libraries which were not installed in the standard library locations. This is true for most complex applications. Typically they need their own set of libraries.

You can check if the linker can locate all the required libraries by running the ldd command.

ldd ~/myprogram

If, for example the linker reports that it cannot find, you need to modify your LD_LIBRARY_PATH  to provide location for it.

Let’s assume this library exists here “~/myprogdir/lib/”. In this case you can set LD_LIBRARY_PATH  the following way:

export LD_LIBRARY_PATH="~/myprogdir/lib/:$LD_LIBRARY_PATH"

Now check the situation again with ldd. The linker has now found all the required libraries.

For more information see

Issues of style and the problem of undefined variables

By default, shell variables are typeless and can be assigned both numeric and non-numeric values.  You need explicitly declare integer variable for shell to know how they should be treated.

While this is not required, a good programming style is to declare all integer variables you use with the declare statement. That means that each variable name will appear in the script at least twice and that allow easy catch misspelling, which are the most common source of errors in bash script.  such errors are difficult to defect because your test case might not cover the branch in which misspelled name is present. So it will be detect much later, possibly in production.

For novices and infrequent users of Bash this is actually a "must" requirement: all variables should be declared using the Bash declare command and option set -o nounset should be set at the very beginning of the script the script.  For example to declare a variable named cores, as integer variable use this:

set -o nounset 
declare -i cores
declare message

Choosing good variable names is important.  The are two requirements here:

Because Bash does minimum checking of variable names, even with the nounset option turned on, another common mistake is using a variable that looks the same. You can declared a variable called nfiles, but in the body of his program use the variable nofiles. So it makes sense to initialize all variables in declare statement

set -o nounset 
declare -i cores=16
printf %d $ncores

Here ncores variable is not initialized and will be detected.


Values can be assigned an initial value when the variable is first declared.

set -o nounset 
declare -i cores=16
printf "%d" $cores

Because declare is a command, variables are created only when the declare command is executed.

The results of a command can also be assigned to a variable. If a command is contained in backquotes ('), everything written to standard output is stored in the variable being assigned instead. For example:

declare -i nfiles=0
nfiles=`ls -1 | wc -l`
printf "%d" $nfiles

Default values assignment as a protection against undefined variables

The most dangerous thing in programming is to assign to other variable the variable without assigned value. Such variables are called "undefined variables". To prevent this from happening Bash provides special construct which checks if the variable was already assigned value, and if not uses instead some "fallback" value.

This makes bash scripts more "error-resistant". Two notations below are slightly different (shell - Test if a variable is set in bash when using set -o nounset - Stack Overflow_

${variable-default}    # - checks whether the variable is empty.
${variable:-default}   # :- checks whether the variable is unset or empty.

For example:

echo "Setting the variable cores"
declare -i cores=10
echo "Printing the value of cores using a default fallback value"
echo "${cores:-2}"
unset -v cores
echo "Printing the value of x using a default fallback value"
echo "${cores:-2}"
echo "Setting the value to null"
echo "Printing the value null"
echo "${cores:-2}  

Now, let's execute it

Variable Attributes

All Bash variables are stored as simple strings. they are kept by Bash in a special table which is constructed by interpreter, which is called identifier table. In additional to its value, each variable has certain options called attributes, which can be turned on or off by using the declare command in a similar way to shell options and the shopt command.

For example, if a variable is declared with the -i (integer) switch, Bash turns on the integer attribute for that variable. the value of the variable is still stored as string, but the treatment of the variable by bash is different the for "normal" variables. For example "normal" arithmetic expressions are allowed.

When Bash encounters this variable in the script, is perform look up in the identifier table and extract both value of the variables and its attributes. If the variable was declared as integer, Bash now knows that the string should be treated as an integer value. If a non-numeric value is assigned to an integer variable, Bash does not report an error but instead assigns a value of zero.

declare -i cores=16
printf "%d\n" "$cores"
cores="16 cores" # mistake -- this is integer variable
printf "%d\n" "$cores"

Sometimes an attempt to assign a string produces an error, but you can't rely on this behavior.

cores="16 cores" # mistake
bash: 16 cores: syntax error in expression 

The attributes of a variable can be displayed with the -p (print) switch.

declare -p cores
declare -i cores="12"

The information is displayed in such a way that it can be saved for use in another script. This allows you to experiment with declarations at the command prompt and then write the declarations to a script file when you are satisfied with the results.

Like the printf command, integer variables can be assigned octal or hexadecimal numbers as well.

declare -i cores=0X0F
printf "%i\n" "$cores"
This will print 15.

Constants are unchanging variables that are created with the -r (read-only) attribute. If you attempt to assign a value to a constant, Bash reports an error. Suppose the constant COMPANY has the name of a company.

declare -r COMPANY="Marsian exploration"
printf "%s\n" "$COMPANY"

Like any other attribute the readonly attribute can be turned off dynamically  using +r declaration. However, this is a very bad  idea: can makes your scripts confusing to read because the reader will assume that a readonly variable is always read-only. Either remove the readonly attribute or change the structure of the script.

More about system variables

Bash has more than 50 system variables. These variables, created when Bash is first started, provide information about the Bash session and can be used to control some of the shell's features.

Some of these variables have special properties that might be lost if you unset the variable and then create a new one with the same name. For example, the variable RANDOM contains a random number, a new one  each time you assign it.  If you delete RANDOM with unset and declare a new variable called RANDOM, this new variable is a normal shell variable and does not contain random numbers. Therefore, it's best to avoid creating variables with the same name as the predefined variables.

The declare command, with no switches, lists all currently defined values.

Linux distributions define additional variables. The presence of these variables depends on your particular distribution. Many are declared for the use of applications.

The Effect of Quotations

Those people familiar with other computer languages might be confused by the way Bash uses quotation marks. Single and double quotes are not used to delineate strings or characters. But sting in double quote is interpreted and valuable are replaced with their values. This is called interpolation of the string

message="running with $cores cores"				

there are some gotchas here.

DATACENTERS="London : Berlin : New York"
printf "%s" $DATACENTERS

The results are still not correct. printf "%s" sees the value of the variable DATACENTERS. this value is London ; Berlin ; New York and it treated it as array of elements, removing the spaces in the process. To avoid this The printf argument should be enclosed in double quotes to keep the value of the variable as a single argument with the spacing intact.

printf "%s" "$DATACENTERS"
London ; Berlin ; New York

Again, it is a safe practice to always enclose variable substitutions with quotes.

Because the quotation marks are not delimiters but hints on how to interpret special characters, they can be used back-to-back. This is a convenient way to separate variables from the surrounding text in a string.

TAX_MESSAGE="The tax is $TAX""%"
printf "%s" "$TAX_MESSAGE"
The tax is 7.25%

Separating each of the quoted pieces with a space would result in the same problem you saw previously: Bash would treat them as three individual values.

Alternatively, a variable substitution's variable name can be enclosed in curly braces to make it clear where the variable's name begins and ends.

TAX_MESSAGE="The tax is ${TAX}%"

Besides space interpretation, another effect of quotation marks is that no pattern matching is done.

Normally, for example, the asterisk (*) represents all the files in the current directory. Quotation marks prevent the asterisk from being replaced with a list of files.

printf "%s\n" *
printf "%s\n" "*"

To print strings without interpreting the special characters inside, use single quotes. Double quotes do not prevent Bash from interpreting the special characters $, ', and \, but single quotes leave all characters unchanged.

printf "%s" '$TAX_MESSAGE'

In this case, the single quotes prevent Bash from interpreting the value as a variable substitution because the dollar sign is not treated specially.

The backslash (\) acts like single quotes for one character, leaving the character unchanged. For example, to print a double quote mark, do this:

printf "%s" "\""

The backslash indicates that the second quote mark is to be treated as a character, not as the ending quote of a pair of quote marks.

The printf formatting code %q (quoting) prints backslashes before every character that has a special meaning to the shell. Use this to ensure that spacing is left intact.

printf "%q" "$TAX_MESSAGE"
The\ tax\ is\ 7.25%

For example, reading from files is affected by %q. If the printed variables contain spaces, read treats the spaces as separators unless they are protected with backslashes.

printf "%q %q\n" "Alpha Systems Inc" "Key West, Florida" > company.txt
read COMPANY LOCATION < company.txt
printf "%s\n" "$COMPANY"
Alpha Systems Inc
printf "%s %s\n" "Alpha Systems Inc" "Key West, Florida" > company.txt
read COMPANY LOCATION < company.txt
printf "%s\n" "$COMPANY"

The read command has no knowledge of what text on the line belonged originally to which variable. It assumes that the values are separated by spaces and assigns Alpha to COMPANY. When %q is used, read knows that the backslash protected spaces belong with the first value and it reads everything up to the first unprotected space, assigning Alpha Systems Inc to COMPANY.

Word splitting is controlled by the value of the special variable IFS. Normally, IFS treats spaces, tabs, and newline characters as word delimiters-that is, it uses whitespace characters. If the content of IFS is changed, the new characters are used as word delimiters. However, this is an older feature for compatibility with the Bourne shell and the IFS variable should not be altered by scripts because newer features such as %q formatting are available.

Whenever values are assigned or are substituted with a dollar sign, it is good practice to always enclose the values in double quotes to prevent problems with values containing spaces.


Arrays are lists of values that are created with the -a (array) attribute.  See also Array Variables

A number called an index refers to the position item in the array. Bash arrays differ from arrays in other computer languages because they are open-ended. Arrays can be any length and are initially filled with empty strings for items.

declare -a matrix

New items are assigned to the array using square brackets to indicate the position in the list. The first position is position zero (not one). If an initial value is specified, it is assigned to the first position. Assigning one value is not particularly useful but is included for compatibility with other shells. Alternatively, the initial values can be assigned to specific positions by including a position in square brackets.

declare -a blades [0]="b1" blades [1]="b2" blades [2]="b8"
Arrays remain in existence until the script ends or until the variable is destroyed with the built-in unset command.
unset blades
The action of this command can be understood if you remember that bash creates a table for each variable it find in the script. when it encounter unset command this line of the table is simple deleted. This is how bash "forget" the variables.

The unset command is a command so it needs to be executed to produce the desired effect.

Because of the square brackets, use curly braces to delineate the variable name and supersede the shell's pathname matching process.

echo "${ DATACENTER [0]}"
echo "${ DATACENTER [2]}"
Morristown  Raleigh

All unassigned positions in an array have no value. The position number 5 in the SERVERS array, for example, is initially an empty string. It can be assigned a value of Dell with an assignment statement.

printf "%s" "${SERVERS[5]}"
printf "%s" "${SERVERS[5]}"

If there is an item in position zero, it is also the value returned when no position is specified.

printf "%s" "$SERVERS"
printf "%s" "${SERVERS[0]}"

The entire array can be accessed using an asterisk (*) or an at sign (@) for the array position. These two symbols differ only when double quotes are used: The asterisk returns one string, with each item separated with the first character of the IFS variable (usually space), and the at sign returns each item as a separate string with no separation character.

printf "%s" "${SERVERS[*]}"
printf "%s" "${SERVERS[@]}"

In this example, the at sign version requires two separate %s formatting codes to display the array properly, one for each array item.

printf "%s %s\n" "${SERVERS[@]}"
HP Dell

Multiple values can be assigned with a list in parentheses.

BRANCHES=("Asia" "North America" "Europe" )
printf "%s\n" "${BRANCHES[*]}"
Asia North America Europe 

The list items can have an optional subscript.

BRANCHES=([1]="Asia" [2]="North America" [3]="Europe"  )
printf "%s\n" "${BRANCHES[*]}"
Asia Europe North America

Combining a list with a declare command, arrays can be assigned values at the time they are created.

The number of items in the array is returned when # is used in front of the variable name with a position of * or @. The items need not be assigned consecutively and the number doesn't reflect where the items are stored.

printf "%d" "${#BRANCHES[*]}"

Individual array values can be removed with the unset command. Erasing a value by assigning the array position an empty string doesn't destroy it: The empty string is still treated as an array item whenever the items are counted.

The read command can read a list into an array using an -a (array) switch. When this switch is used, each item on the line of input is read into a separate array position.

The array attribute is the only variable attribute that cannot be turned off after it is turned on. If Bash allowed the attribute to be turned off, the data in the array would be lost when the array became a normal variable.

Exporting Variables and the Linux Environment

Shell variables exist in the script or interactive sessions only where they were declared. In order to make shell variables available outside of their place of origin, they have to be declared as exportable. Variables are marked as exportable with the export attribute using the declare -x (export) switch. The export attribute reminds the shell that you want to “export,” or provide the variable, to all programs run by the script.

For example, the program SGE schedule requires a variable called SGE_ROOT to exist for all its programs.

declare -x SGE_ROOT="/opt/sge"

this is the same as

export SGE_ROOT="/opt/sge"

Important variables declared in your profile scripts must be exported so that they are available for all sub processes, not only for main session.

Export works only in relation to subprocess not "backward to the program that launched particular script. When a variable is exported, any changes made by programs executed by the script are discarded when the program completes. At this point all changes in environment are “rolled back.”

you can make  global constants by using both the export and read-only switches.

declare -rx SGE_ROOT="/opt/sge"

that means that  SGE_ROOT is only a read-only variable in the current script. When it's exported to a second script, it's exported as a normal variable-the read-only effect is lost. The reason for this strange behavior is rooted in the way Linux shares environment variables between programs and has nothing to do with the Bash shell itself.

Environment variables are the variables Linux shares between a program and the program that executed it. Like layers of an onion, each program must explicitly export a variable into the environment for the next program to see it.

Although Linux has provisions for exporting environment variables, there is no way to assign any attributes to them. Linux has no notion of attributes. Bash attributes were thought up after environment variables were first invented. When Bash variables are given to Linux to share with a new program, the attributes are lost. When the second shell script starts, it has no way of knowing what the original attributes were.

The variables shared with a new program are copies of the original. If a script declares an exported variable and runs a second script, any changes made to the variable by the second script are invisible to the first. There is no way for a second script to assign a new value to a variable that the first script will see. Unlike other programming languages, exporting shell variables is a one-way street.

Suppose there are two scripts called and declares a variable and then runs the script,

# This script runs first.

declare -rx TEST_SUBSTANCE="metformin"
printf "%s\n" "$TEST_SUBSTANCE"

exit 0

Listing 5.2.
# This script is run by

printf "This is the inner script.\n"

printf "%s\n" "$TEST_SUBSTANCE"

printf "Inner script finished\n"

exit 0

When is run, the TEST_SUBSTANCE variable is read-only. However, inside, the read-only attribute has been lost. changes the variable to a new value, but when is finished, shows that the variable's value is unchanged.

The only way to return a value to the calling program is to write it to a file (or standard output) and have the calling program read (or assign) the value back into a variable.

The eval Command

Bash performs variable substitutions as variables are encountered in a command , double quoted strings and backticked string or thier equvalents. But if a value of any variable contains dollar sign it will neve be  expanded even if it corresponds to a valid variable name

declare -rx COMPANY="Value Book Resellers"
declare -rx TITLE='$COMPANY'
printf "%s\n" "$TITLE"

Before the printf is performed, Bash substitutes the value "$COMPANY" for TITLE. Bash does not repeat the substitution process to replace the COMPANY variable with "Value Book Resellers". Substitutions are performed only once.

If you need such  substitution to be perofmed you need to use bash eval command. It  treats the string that you provide to it as a script and executes it.

 Variables and constants form the building blocks of all scripts, but they only serve as storage containers without expressions. These are covered in the next chapter (Chapter 6, “Expressions”).

variable substitution. Let us carefully distinguish between the name of a variable and its value. If variable1 is the name of a variable, then $variable1 is a reference to its value, the data item it contains. The only time a variable appears "naked", without the $, is when declared or assigned (or when exported). Assignment may be with an = (as in var1=27), in a read statement, and at the head of a loop (for var2 in 1 2 3).

Enclosing a referenced value in double quotes (" ") does not interfere with variable substitution. This is called partial quoting, sometimes referred to as "weak quoting". Using single quotes (' ') causes the variable name to be used literally, and no substitution will take place. This is full quoting, sometimes referred to as "strong quoting".

Note that $variable is actually a simplified alternate form of ${variable}. In contexts where the $variable syntax causes an error, the longer form may work

Example 3-5. Variable assignment and substitution

   1 #!/bin/bash
   3 # Variables: assignment and substitution
   5 a=37.5
   6 hello=$a
   7 # No space permitted on either side of = sign when initializing variables.
   9 echo hello
  10 # Not a reference.
  12 echo $hello
  13 echo ${hello} #Identical to above.
  15 echo "$hello"
  16 echo "${hello}"
  18 echo '$hello'
  19 # Variable referencing disabled by single quotes,
  20 # because interpreted literally.
  22 # Notice the effect of different types of quoting.
  24 # --------------------------------------------------------------
  26 # It is permissible to set multiple variables on the same line,
  27 # separated by white space. Careful, this may reduce legibility.
  29 var1=variable1  var2=variable2  var3=variable3
  30 echo
  31 echo "var1=$var1   var2=$var2  var3=$var3"
  33 # --------------------------------------------------------------
  35 echo; echo
  37 numbers="one two three"
  38 other_numbers="1 2 3"
  39 # If whitespace within variables, then quotes necessary.
  40 echo "numbers = $numbers"
  41 echo "other_numbers = $other_numbers"
  42 echo
  44 echo "uninitialized variable = $uninitialized_variable"
  45 # Uninitialized variable has null value (no value at all).
  47 echo
  49 exit 0

! An uninitialized variable has a "null" value - no assigned value at all (not zero!). Using a variable before assigning a value to it will inevitably cause problems.

Parameter Substitution

Same as $parameter, i.e., value of the variable parameter.

May be used for concatenating variables with strings.

   1 your_id=${USER}-on-${HOSTNAME}
   2 echo "$your_id"
   3 #
   4 echo "Old \$PATH = $PATH"
   5 PATH=${PATH}:/opt/bin  #Add /opt/bin to $PATH for duration of script.
   6 echo "New \$PATH = $PATH"

If parameter not set, use default.
   1 echo ${username-`whoami`}
   2 # Echoes the result of `whoami`, but variable "username" is still unset.
! This is almost equivalent to ${parameter:-default}. The extra : makes a difference only when parameter has been declared, but is null.


   1 #!/bin/bash
   3 username0=
   4 echo "username0 = ${username0-`whoami`}"
   5 # username0 has been declared, but is set to null.
   6 # Will not echo.
   8 echo "username1 = ${username1-`whoami`}"
   9 # username1 has not been declared.
  10 # Will echo.
  12 username2=
  13 echo "username2 = ${username2:-`whoami`}"
  14 # username2 has been declared, but is set to null.
  15 # Will echo because of :- rather than just - in condition test.
  17 exit 0

${parameter=default}, ${parameter:=default}
If parameter not set, set it to default.

Both forms nearly equivalent. The : makes a difference only when parameter has been declared and is null, as above.


   1 echo ${username=`whoami`}
   2 # Variable "username" is now set to `whoami`.

${parameter+otherwise}, ${parameter:+otherwise}
If parameter set, use 'otherwise", else use null string.

Both forms nearly equivalent. The : makes a difference only when parameter has been declared and is null, as above.

${parameter?err_msg}, ${parameter:?err_msg}
If parameter set, use it, else print err_msg.

Both forms nearly equivalent. The : makes a difference only when parameter has been declared and is null, as above.


   1 #!/bin/bash
   3 # Let's check some of the system's environmental variables.
   4 # If, for example, $USER, the name of the person
   5 # at the console, is not set, the machine will not
   6 # recognize you.
   8 : ${HOSTNAME?} ${USER?} ${HOME} ${MAIL?}
   9   echo
  10   echo "Name of the machine is $HOSTNAME."
  11   echo "You are $USER."
  12   echo "Your home directory is $HOME."
  13   echo "Your mail INBOX is located in $MAIL."
  14   echo
  15   echo "If you are reading this message,"
  16   echo "critical environmental variables have been set."
  17   echo
  18   echo
  20 # The ':' operator seems fairly error tolerant.
  21 # This script works even if the '$' omitted in front of
  22 # {HOSTNAME}, {USER?}, {HOME?}, and {MAIL?}. Why?
  24 # ------------------------------------------------------
  26 # The ${variablename?} construction can also check
  27 # for variables set within the script.
  29 ThisVariable=Value-of-ThisVariable
  30 # Note, by the way, that string variables may be set
  31 # to characers disallowed in their names.
  32 : ${ThisVariable?}
  33 echo "Value of ThisVariable is $ThisVariable".
  34 echo
  35 echo
  37 # If ZZXy23AB has not been set...
  38 : ${ZZXy23AB?}
  39 # This will give you an error message and terminate.
  41 echo "You will not see this message."
  43 exit 0 
Parameter substitution and/or expansion. The following expressions are the complement to the b>match in expr string operations (see Example 3-52). These particular ones are used mostly in parsing file path names.
${var#pattern}, ${var##pattern}
Strip off shortest/longest part of pattern if it matches the front end of variable.
${var%pattern}, ${var%%pattern}
Strip off shortest/longest part of pattern if it matches the back end of variable.

Version 2 of bash adds additional options.


   1 #!/bin/bash
   3 #                 rfe
   4 #                 ---
   6 # Renaming file extensions.
   7 #
   8 #         rfe old_extension new_extension
   9 #
  10 # Example:
  11 # To rename all *.gif files in working directory to *.jpg,
  12 #          rfe gif jpg
  14 if [ $# -ne 2 ]
  15 then
  16   echo "Usage: `basename $0` old_file_suffix new_file_suffix"
  17   exit 1
  18 fi
  20 for filename in *.$1
  21 # Traverse list of files ending with 1st argument.
  22 do
  23   mv $filename ${filename%$1}$2
  24   # Strip off part of filename matching 1st argument,
  25   # then append 2nd argument.
  26 done
  28 exit 0

Variable var expanded, starting from offset pos.
Expansion to a max of len characters of variable var, from offset pos. See Example A-6 for an example of the creative use of this operator.
First match of patt, within var replaced with replacement.

If replacement is omitted, then the first match of patt is replaced by nothing, that is, deleted.

All matches of patt, within var  replaced with replacement.

Similar to above, if replacement is omitted, then all occurrences patt are replaced by nothing, that is, deleted.


   1 #!/bin/bash
   3 var1=abcd-1234-defg
   4 echo "var1 = $var1"
   6 t=${var1#*-*}
   7 echo "var1 (with everything, up to and including first - stripped out) = $t"
   8 t=${var1%*-*}
   9 echo "var1 (with everything from the last - on stripped out) = $t"
  11 echo
  13 path_name=/home/bozo/ideas/
  14 echo "path_name = $path_name"
  15 t=${path_name##/*/}
  16 # Same effect as   t=`basename $path_name`
  17 echo "path_name, stripped of prefixes = $t"
  18 t=${path_name%/*.*}
  19 # Same effect as   t=`dirname $path_name`
  20 echo "path_name, stripped of suffixes = $t"
  22 echo
  24 t=${path_name:11}
  25 echo "$path_name, with first 11 chars stripped off = $t"
  26 t=${path_name:11:5}
  27 echo "$path_name, with first 11 chars stripped off, length 5 = $t"
  29 echo
  31 t=${path_name/bozo/clown}
  32 echo "$path_name with \"bozo\" replaced  by \"clown\" = $t"
  33 t=${path_name/today/}
  34 echo "$path_name with \"today\" deleted = $t"
  35 t=${path_name//o/O}
  36 echo "$path_name with all o's capitalized = $t"
  37 t=${path_name//o/}
  38 echo "$path_name with all o's deleted = $t"
  40 exit 0

There are several built-in variables which are set or used by Bash:

The full pathname used to execute the current instance of Bash.
If this variable is set when Bash is invoked to execute a shell script, its value is expanded and used as the name of a startup file to read before executing the script. See section Bash Startup Files.
The version number of the current instance of Bash.
A readonly array variable (see section Arrays) whose members hold version information for this instance of Bash. The values assigned to the array members are as follows:
The major version number (the release).
The minor version number (the version).
The patch level.
The build version.
The release status (e.g., beta1).
The value of MACHTYPE.
Used by the select builtin command to determine the terminal width when printing selection lists. Automatically set upon receipt of a SIGWINCH.
An index into ${COMP_WORDS} of the word containing the current cursor position. This variable is available only in shell functions invoked by the programmable completion facilities (see section 8.6 Programmable Completion).
The current command line. This variable is available only in shell functions and external commands invoked by the programmable completion facilities (see section 8.6 Programmable Completion).
The index of the current cursor position relative to the beginning of the current command. If the current cursor position is at the end of the current command, the value of this variable is equal to ${#COMP_LINE}. This variable is available only in shell functions and external commands invoked by the programmable completion facilities (see section 8.6 Programmable Completion)
An array variable consisting of the individual words in the current command line. This variable is available only in shell functions invoked by the programmable completion facilities (see section 8.6 Programmable Completion).
An array variable from which Bash reads the possible completions generated by a shell function invoked by the programmable completion facility (see section 8.6 Programmable Completion).
An array variable containing the current contents of the directory stack. Directories appear in the stack in the order they are displayed by the dirs builtin. Assigning to members of this array variable may be used to modify directories already in the stack, but the pushd and popd builtins must be used to add and remove directories. Assignment to this variable will not change the current directory. If DIRSTACK is unset, it loses its special properties, even if it is subsequently reset.
The numeric effective user id of the current user. This variable is readonly.
The editor used as a default by the `-e' option to the fc builtin command.
A colon-separated list of suffixes to ignore when performing filename completion. A file name whose suffix matches one of the entries in FIGNORE is excluded from the list of matched file names. A sample value is `.o:~'
The name of any currently-executing shell function. This variable exists only when a shell function is executing. Assignments to FUNCNAME have no effect and return an error status. If FUNCNAME is unset, it loses its special properties, even if it is subsequently reset.
A colon-separated list of patterns defining the set of filenames to be ignored by filename expansion. If a filename matched by a filename expansion pattern also matches one of the patterns in GLOBIGNORE, it is removed from the list of matches.
An array variable containing the list of groups of which the current user is a member. Assignments to GROUPS have no effect and return an error status. If GROUPS is unset, it loses its special properties, even if it is subsequently reset.
Up to three characters which control history expansion, quick substitution, and tokenization (see section 9.3 History Expansion). The first character is the history expansion character, that is, the character which signifies the start of a history expansion, normally `!'. The second character is the character which signifies `quick substitution' when seen as the first character on a line, normally `^'. The optional third character is the character which indicates that the remainder of the line is a comment when found as the first character of a word, usually `#'. The history comment character causes history substitution to be skipped for the remaining words on the line. It does not necessarily cause the shell parser to treat the rest of the line as a comment.
The history number, or index in the history list, of the current command. If HISTCMD is unset, it loses its special properties, even if it is subsequently reset.
A value of `ignorespace' means to not enter lines which begin with a space or tab into the history list. A value of `ignoredups' means to not enter lines which match the last entered line. A value of `ignoreboth' combines the two options. Unset, or set to any other value than those above, means to save all lines on the history list. The second and subsequent lines of a multi-line compound command are not tested, and are added to the history regardless of the value of HISTCONTROL.
The name of the file to which the command history is saved. The default value is `~/.bash_history'.
The maximum number of lines contained in the history file. When this variable is assigned a value, the history file is truncated, if necessary, to contain no more than that number of lines. The history file is also truncated to this size after writing it when an interactive shell exits. The default value is 500.
A colon-separated list of patterns used to decide which command lines should be saved on the history list. Each pattern is anchored at the beginning of the line and must match the complete line (no implicit `*' is appended). Each pattern is tested against the line after the checks specified by HISTCONTROL are applied. In addition to the normal shell pattern matching characters, `&' matches the previous history line. `&' may be escaped using a backslash; the backslash is removed before attempting a match. The second and subsequent lines of a multi-line compound command are not tested, and are added to the history regardless of the value of HISTIGNORE.

HISTIGNORE subsumes the function of HISTCONTROL. A pattern of `&' is identical to ignoredups, and a pattern of `[ ]*' is identical to ignorespace. Combining these two patterns, separating them with a colon, provides the functionality of ignoreboth.

The maximum number of commands to remember on the history list. The default value is 500.
Contains the name of a file in the same format as `/etc/hosts' that should be read when the shell needs to complete a hostname. The list of possible hostname completions may be changed while the shell is running; the next time hostname completion is attempted after the value is changed, Bash adds the contents of the new file to the existing list. If HOSTFILE is set, but has no value, Bash attempts to read `/etc/hosts' to obtain the list of possible hostname completions. When HOSTFILE is unset, the hostname list is cleared.
The name of the current host.
A string describing the machine Bash is running on.
Controls the action of the shell on receipt of an EOF character as the sole input. If set, the value denotes the number of consecutive EOF characters that can be read as the first character on an input line before the shell will exit. If the variable exists but does not have a numeric value (or has no value) then the default is 10. If the variable does not exist, then EOF signifies the end of input to the shell. This is only in effect for interactive shells.
The name of the Readline initialization file, overriding the default of `~/.inputrc'.
Used to determine the locale category for any category not specifically selected with a variable starting with LC_.
This variable overrides the value of LANG and any other LC_ variable specifying a locale category.
This variable determines the collation order used when sorting the results of filename expansion, and determines the behavior of range expressions, equivalence classes, and collating sequences within filename expansion and pattern matching (see section 3.5.8 Filename Expansion).
This variable determines the interpretation of characters and the behavior of character classes within filename expansion and pattern matching (see section 3.5.8 Filename Expansion).
This variable determines the locale used to translate double-quoted strings preceded by a `$' (see section Locale-Specific Translation).
This variable determines the locale category used for number formatting.
The line number in the script or shell function currently executing.
Used by the select builtin command to determine the column length for printing selection lists. Automatically set upon receipt of a SIGWINCH.
A string that fully describes the system type on which Bash is executing, in the standard GNU cpu-company-system format.
How often (in seconds) that the shell should check for mail in the files specified in the MAILPATH or MAIL variables. The default is 60 seconds. When it is time to check for mail, the shell does so before displaying the primary prompt. If this variable is unset, or set to a value that is not a number greater than or equal to zero, the shell disables mail checking.
The previous working directory as set by the cd builtin.
If set to the value 1, Bash displays error messages generated by the getopts builtin command.
A string describing the operating system Bash is running on.
An array variable (see section 6.7 Arrays) containing a list of exit status values from the processes in the most-recently-executed foreground pipeline (which may contain only a single command).
If this variable is in the environment when bash starts, the shell enters POSIX mode (see section 6.11 Bash POSIX Mode) before reading the startup files, as if the `--posix' invocation option had been supplied. If it is set while the shell is running, bash enables POSIX mode, as if the command
set -o posix
had been executed.
The process ID of the shell's parent process. This variable is readonly.
If set, the value is interpreted as a command to execute before the printing of each primary prompt ($PS1).
The value of this variable is used as the prompt for the select command. If this variable is not set, the select command prompts with `#? '
The value is the prompt printed before the command line is echoed when the `-x' option is set (see section 4.3 The Set Builtin). The first character of PS4 is replicated multiple times, as necessary, to indicate multiple levels of indirection. The default is `+ '.
The current working directory as set by the cd builtin.
Each time this parameter is referenced, a random integer between 0 and 32767 is generated. Assigning a value to this variable seeds the random number generator.
The default variable for the read builtin.
This variable expands to the number of seconds since the shell was started. Assignment to this variable resets the count to the value assigned, and the expanded value becomes the value assigned plus the number of seconds since the assignment.
A colon-separated list of enabled shell options. Each word in the list is a valid argument for the `-o' option to the set builtin command (see section 4.3 The Set Builtin). The options appearing in SHELLOPTS are those reported as `on' by `set -o'. If this variable is in the environment when Bash starts up, each shell option in the list will be enabled before reading any startup files. This variable is readonly.
Incremented by one each time a new instance of Bash is started. This is intended to be a count of how deeply your Bash shells are nested.
The value of this parameter is used as a format string specifying how the timing information for pipelines prefixed with the time reserved word should be displayed. The `%' character introduces an escape sequence that is expanded to a time value or other information. The escape sequences and their meanings are as follows; the braces denote optional portions.
A literal `%'.

The elapsed time in seconds.

The number of CPU seconds spent in user mode.
The number of CPU seconds spent in system mode.

The CPU percentage, computed as (%U + %S) / %R.

The optional p is a digit specifying the precision, the number of fractional digits after a decimal point. A value of 0 causes no decimal point or fraction to be output. At most three places after the decimal point may be specified; values of p greater than 3 are changed to 3. If p is not specified, the value 3 is used.

The optional l specifies a longer format, including minutes, of the form MMmSS.FFs. The value of p determines whether or not the fraction is included.

If this variable is not set, Bash acts as if it had the value

If the value is null, no timing information is displayed. A trailing newline is added when the format string is displayed.
If set to a value greater than zero, the value is interpreted as the number of seconds to wait for input after issuing the primary prompt when the shell is interactive. Bash terminates after that number of seconds if input does not arrive.
The numeric real user id of the current user. This variable is readonly.

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

Top articles


Top articles




FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  


Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: September 12, 2017