What's New!

Chat with

How to Defend
Your Computer 

The Guides
to (mostly) 
Harmless Hacking

Happy Hacker 
Digests (old stuff) 

Hacker Links 


Meet the 
Happy Hacksters 

Help for 



It Sucks 
to Be Me!

How to Commit
Computer Crime (not)! 

What Is a 
Hacker, Anyhow? 

Have a 
Great Life! 

News from the 
Hacker War Front

The Bash Shell,continued...


    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"
set| grep "hi_test"

    You will have nothing returned back. Whereas if you had done:

export hi_test="Hi, this is TEST"
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:


    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:


    Don't worry if yours is slightly different. Now you can create and reference variables.

More on the bash shell --->> 

Carolyn's most
popular book,
in 4th edition now!
For advanced
hacker studies,
read Carolyn's
Google Groups
Subscribe to Happy Hacker
Visit this group


Return to the index of Guides to (mostly) Harmless Hacking!

 © 2013 Happy Hacker All rights reserved.