Scripting : You Can Do It
“Shell scripting” sounds like a really scary topic. Isn’t scripting for uber-geeks? Unix gurus? Isn’t scripting really spooky stuff?
It isn’t if you already know how to open a command window, change directories, and copy and move files. You’ve already got the basic tools. Promise.
The only difference between a shell script and the commands you’d normally use at the command prompt is that you’ll save your commands to a file. A shell script is no more than a list of commands that are run in sequence.
Now you’re going to write a script. You’re going to need to create a file called hello.sh .
Use the command:
If you’re using gedit or kedit, use a command like:
gedit hello.sh &
#Don’t forget that & !
To begin, a shell script has to start with a line like this:
depending on the system. This line indicates that the script should be run in the Bourne/bash shell regardless of which interactive shell the user has chosen. This is very important, since the syntax of different shells can vary greatly. Generically, the #! symbol is called a “shebang” (my preference) or a “hashpling.”
Take a good look at the line again:
It’s very easy to make a mistake right here that will cause an error:
You must not leave a space after the bang.
There are a few command interpreters that can handle it; most can’t.
Here’s a very simple example of a shell script for you to copy. It runs a few simple commands:
echo “Hello, $USER.” # list user’s files
echo “Your current directory is $PWD”
# list files
echo “It contains these files:” `ls`
Notice that this script uses a command (echo) to call a command (ls -la), and employs two environmental variables ($USER and $PWD). Not bad for a start! Now copy this script.
- Run this script. How do you call it?
- What else do you need to do to make it run?
See the comment on line three:
# list files
In a Bourne/bash script, anything following a pound sign # (besides the shell name on the first line) is a comment: the shell ignores it. It is there for the benefit of people reading the script.
$USER and $PWD are environment variables. These are standard variables defined outside the Bourne/bash shell itself, so they needn’t be defined in the script.
Variables are expanded when the variable name is inside double quotes. “Expanded” is an appropriate word: the shell sees the string $USER and replaces it with the variable’s value.
You define a variable and give it a value like this:
You get a value back out of it by referring to it as:
For instance, you can see X’s value by echoing it to the screen:
Formally, $X is used to denote the value of the variable X.
No Spaces With =
Your shell will be very unhappy if you leave a space on either side of the = sign.
For example, try both the following:
X = hello
Technically, you don’t need quotes unless your variable names include spaces. For example,
X=hello world # error
X=”hello world” # good
This is because the shell essentially sees the command line as a string of commands and command arguments, separated by spaces. (Read that twice more.)
is considered a command (which it is: it’s the assignment command in action). The problem with
foo = bar
is that the shell sees the word foo separated by spaces and interprets it as a command. Likewise, the problem with the command
is that the shell interprets X=hello as a command, and the word “world” doesn’t make any sense as its argument either.
The one critical thing you must remember about script files is this:
You must make the script file executable in order for it to run.
This means you must change its mode.
Make your script executable with either of the following commands:
chmod +x hello.sh
chmod 755 hello.sh
Now you can run your script with the simple command:
- For whom is the script now executable?
- Under what user’s permissions will it run?
- How could you avoid having to use ./ ?
If a script has been made executable, you can run it simply by calling its name:
There is a way around the executable limitation. If you have read access to the script, you can call the script by opening a new Bash subshell, using the script’s name as an argument:
This leads to a good point: you can run many kinds of script files be specifying the shell or interpreter (for instance, the Perl or PHP interpreter, or the C shell) and the script name: