Shell scripting can be a wonderful language to code in. With the power of calling any other application on the command line, you can integrate shell scripts with just about anything. We show you how to get started.
Every good shell script should start with a "hashbang". This is the first line of the shell script which tells the running shell what interpreter to use. For example, the following code tells the running shell to use the Bash language for running the code. Without this first line, the script would run in whatever shell language called the script.
#!/bin/bash echo This is my bash shell script
You can use the "whereis" command to check for the location of the interpreter you need. For example:
sh$ which perl /usr/bin/perl
This tells me that the perl command lives at /usr/bin/perl, so if I want to use this in a script I might write it like this:
#!/usr/bin/perl print "This is my perl script\n";
There are two common ways to run a shell script. First, you can call a command interpreter with the filename of the script, like this:
sh$ bash /home/doug/myShellScript.sh
The first way ignores the "hashbang" at the top of the script is ignored, and the called command interpreter is used. The second way is more common, and that is just to call the name of the script:
sh$ /home/doug/myShellScript.sh
For the second method to work, the script needs to be called with the full path, or the directory containing the script should be in your PATH (see Shell Variables). The script also needs to be executable by the user. This can be achieved by using the "chmod" command. In this example we try and run a script which is not executable. It fails, but we make it executable and it succeeds:
sh$ /home/doug/myShellScript.sh sh: /home/doug/myShellScript.sh: Permission denied sh$ chmod u+x /home/doug/myShellScript.sh sh$ /home/doug/myShellScript.sh This is my bash shell script
Comments in shell scripts start with a hash (#), like this:
#!/bin/bash # This is a comment echo This is my bash shell script
Are you getting an error like this:
: bad interpreter: No such file or directory
or this:
bash: ./test.sh: /bin/sh^M: bad interpreter: No such file or directory
or this?
^M: not found
Old UNIX hands may tease you about this one, so we'll keep this between the two of us. Windows text files usually end lines with a "newline" character, then a "carriage return" character, whereas UNIX systems usually expect just a "newline" character at the end of a line. If the shell interpreter comes across a "carriage return" it tries to interpret it, not as part of the end of the line, but as some part of a command.
It's not so easy to see carriage returns, but we can check for them in code by running something as in the following example. Simply replace "test.sh" for the name of the file you want to check, and it should highlight carriage returns as "<CR>".
sh$ cat test.sh | perl -pe 's/\r/<CR>/' #!/bin/sh<CR> <CR> echo this is a test<CR> <CR>
Now we know we have this issue, we can use the dos2unix command to remove these pesky carriage returns, like this:
sh$ dos2unix test.sh