The Bash Shell,continued...
Processes
The concept of the environment now comes
into full effect. When you are in your bash shell and you execute
a command or script, that command INHERITS it's parent process's
environment. The shell in this case is the parent process, and
the command or script you run is the child process. This child
process can in turn start a child process of it's own. The concept
of child and parent is relative to which process you are talking
about. Any process that starts a child becomes that child's parent.
Much like in real life. You are a child, but may eventually become
a parent as well.
Init is the Mother Of All Processes. Think
of it as god if you are religious. If you're not religious,
think of it as a The Big Bang. Or anything else that pleases
you.
To see how your children and their parents
are doing, use the command 'pstree', or if you don't have that,
'ps -f' to get a list of every process running and how it relates
to init.
Are we going off on a tangent? Probably...anyway,
when you type a command, you will notice a variable called $_
is being set. We'll see soon what this is actually doing.
Let's try an example. Type this:
set hi_temp="Hi, this is TEMP"
set | less
Note: if you don't have less, use more.
;)
You will see at this point, no variable called
$hi_temp. but at the bottom, you should see
=hi_temp=Hi, This is TEMP
Then type:
set hi_test="Hi, this is TEST"
set | less
Take note there is now no reference to
"hi_temp". But one of the last lines should read "_=hi_test=Hi,
this is TEST."
The variable $_ is actually just a reminder
of the last command you typed, not a place to remember set commands.
You will find very quickly that unless you explicitly use export
in the first instance in the shell (not in a script file), you
will not be able to export to the environment. This is because
the set command runs as a child process which eats it's own variables.
You can prove this to yourself by doing
the following:
set hi_test="Hi, this is TEST"
ls
set| grep "hi_test"
You will have nothing returned back. Whereas
if you had done:
export hi_test="Hi, this is TEST"
ls
set | grep "hi_test"
Bash will return:
hi_test=Hi, this is TEST
Once the variable is in the environment,
it can be accessed by the child processes. Note that the parent
process will not inherit any variables from the children. This
is very dangerous.
In scripts, if you are setting variables to be
used locally in the
script, you won't have to export. But if you wish for those processes
your script calls, ie, another script, then you will have to
export.
More on Variables
To reference variables on the command line
or in your scripts, you will have to prepend the variable name
with the String symbol, or the dollar sign ($). Take the following
simple example entered at the command line
export HI=hello
echo "$HI"
The output after the echo command is:
hello
If you had just typed 'echo "HI"'
as your last command, what do you think would have been displayed?
All those who replied 'HI' get to buy themselves a chocolate
fish. Note that after the echo command, no matter whether we
are using variables or not, I use quote marks (") before
and after the string to be echoed. This is best shown by example.
Type the following at the prompt:
export HI="*"
echo $HI
You will get the equivalent of the current
directory's listing dumped out. But if you go:
echo "$HI"
Bash will display
*
Which is what you wanted. IE; the CONTENTS
of the variable. bash likes to substitute commands before executing.
Remember when to use quotes and you will be fine.
To display a variable already set in place,
you just use echo, eg:
echo "$PS1"
Will probably give you:
\h:\w\$
Don't worry if yours is slightly different.
Now you can create and reference variables.
More on the bash shell --->>
