That was a very commendable idea. Now let us go over the script. First, its "big structure":
#!/bin/sh
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/entity/bin //designate the various path's so that the shell knows where to look for executable's
data_dir=/usr/local/entity/project //designate a location where the shell can store information (does not seem to be used in the script)
SOUNDMANAGER=bmsoundmanager //give the bmsoundmanager a variable or an alias in this case "SOUNDMANAGER" the bmsoundmanager
//is a program within entity/bin which controls various aspects
//of the sound system, it is an extension of SoundManagerAlsa
start() {
[...]
}
stop() {
[...]
}
case "$1" in
"start")
start
;;
"stop")
stop
echo "OK"
;;
reload|restart)
stop
sleep 1
start
;;
*)
echo "$0: unknown argument $1." >&2;
;;
esac
The first thing you need to know is: Every shell script has a "main" part, like every C program has a "main()" function. Alas, the main part is not denoted as such. It is just, what remains after (or rather "outside" of) all the function definitions. I suppose you know from other languages what a function is. Here we have two functions: start() and stop(). One is supposed to start the program, one to stop the program. Functions are just read in and used only when they are called. So, this is the main part, which is executed first when the program is executed:
#!/bin/sh
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/entity/bin //designate the various path's so that the shell knows where to look for executable's
data_dir=/usr/local/entity/project //designate a location where the shell can store information (does not seem to be used in the script)
SOUNDMANAGER=bmsoundmanager //give the bmsoundmanager a variable or an alias in this case "SOUNDMANAGER" the bmsoundmanager
//is a program within entity/bin which controls various aspects
//of the sound system, it is an extension of SoundManagerAlsa
case "$1" in
"start")
start
;;
"stop")
stop
echo "OK"
;;
reload|restart)
stop
sleep 1
start
;;
*)
echo "$0: unknown argument $1." >&2;
;;
esac
First thing to notice is line 1:
#!/bin/sh
This tells the operating system which commando processor to use. A typical UNIX (or Linux) system has several possible commando processors (=shells), one of which is the "default shell", which is usually located in /bin/sh . All shells in UNIX are not only a (text-based) surface to the operating system but also a scripting language. Since the scripting languages of the most widely spread shells (the "Bourne shell" and its successors "Korn shell" and "bash") are very similar but not exactly the same this makes sure that the OS does not have to decide which commando processor to use but is told exactly about the one it should call and then feed it the script.
Next thing: "$0", "$1", ...
[...]
case "$1" in
[...]
echo "$0: unknown argument $1." >&2;
There are some variables the shell maintains itself and any script can use them. "$0" is the name of the program itself, as it is called. Here is an exercise for you: create a directory in /tmp named "myprogram". Then put a file named "firstprog.sh" there with this content:
#! /bin/sh
echo "The name of this program is $0"
exit 0
Then make it executable, here is the whole procedure, which you can cut & paste on the command prompt. How it works should (for now) not be your concern, it uses some advanced features:
mkdir -p /tmp/myprogram
cat > /tmp/myprogram/firstprog.sh <<-EOF
#! /bin/sh
echo "The name of this program is \$0"
exit 0
EOF
chmod 754 /tmp/myprogram/firstprog.sh
After this you have a file /tmp/myprogram/firstprog.sh which you can look at:
$ ls -l /tmp/myprogram
total 4
-rwxr-xr-- 1 bakunin users 57 Dec 28 20:52 firstprog.sh
and which you can exectue. First, change into the directory and call it this way:
$ cd /tmp/myprogram
$ ./firstprog.sh
The name of this program is ./firstprog.sh
Now change to your home directory (the cd shell builtin without an argument will get you there) and try again, using the full path:
$ cd
$ /tmp/myprogram/firstprog.sh
The name of this program is /tmp/myprogram/firstprog.sh
You see the difference? This is what $0 is for. The other variables with numbers ( $1 , $2 , ...) are the (first, second, ...) representation of the commandline argument(s) given to the program inside of it. We will change our example script a little and see how that works:
mkdir -p /tmp/myprogram
cat > /tmp/myprogram/firstprog.sh <<-EOF
#! /bin/sh
echo "The first argument was: \$1"
echo "The second argument was: \$2"
echo "The third argument was: \$3"
exit 0
EOF
chmod 754 /tmp/myprogram/firstprog.sh
Now try the following calls of this program one after the other. Observe the result:
$ /tmp/myprogram/firstprog.sh one two three
$ /tmp/myprogram/firstprog.sh one "two three"
$ /tmp/myprogram/firstprog.sh one "two three" four
$ /tmp/myprogram/firstprog.sh one two three four five
$ /tmp/myprogram/firstprog.sh
What have we seen? First, the variables $1, $2 and so on are filled on a "first come first served" basis. If there are less command line arguments than there are variables some (or maybe even all if there are no arguments) simply are empty. Second: normally the shell is separating arguments along word boundaries: "two" and "three" were separated because there was a white space in between. With the use of quotation (see the second example) you can switch this behavior off and create arguments which contain whitespace. Notice that both double and single quotes will have this effect although there are subtle differences between them which i will not address yet. Now, in light of this, let us try to examine what the main program does:
#!/bin/sh
case "$1" in
"start")
start
;;
"stop")
stop
echo "OK"
;;
reload|restart)
stop
sleep 1
start
;;
*)
echo "$0: unknown argument $1." >&2;
;;
esac
You see: the program can be called with a single commandline argument (it can be called with more too but it will ignore them since only "$1" is used). This argument can be one word out of the following:
1) "start"
2) "stop"
3) "reload"
4) "restart"
"start" will call the start function, "stop" will call the stop function, "reload" and "restart" will do the same, namely, first call the stop function, then wait for 1 second ("sleep 1"), then call the start function. Every other value of the first argument will lead to an error message of "unknown argument" and the name of the program so that the user knows which program this error message comes from.
There is nothing more disappointing than having dozens of scripts executed at system start and you get an error message of "failed" without an indication of what failed and why. When you start to program: don't do that to your users. Every script fails from time to time. That is nothing bad. Bad is to deny the user the means to find out why it failed, exactly where it failed and why. A well-written script can do complex things and its output will read like this:
did thing 1: success
did thing 2: success
did thing 3: failed
cannot do ....
exit 1
A badly written script will just write "failed" and be done. Now find out which of the possibly 25 things the script could do exactly failed and you start to call the programmer every swear name in your vocabulary.
OK, i stop ranting here. You sure are eager to further analyse your script in light of what i said.
I hope this helps.
bakunin