This scripting miniseries will help you learn some basic scripting and perhaps launch you on a more productive career in Linux system administration. If you find yourself typing the same commands over and over again, do yourself a favor and write a script to do it. Smart administrators have scripts for everything. There are three things you have to remember about scripting: Don’t test your scripts on production systems, document the script’s action, and name the script descriptively. This week’s article introduces you to simple shell scripting.
There’s no great secret to creating good scripts. You don’t have to be afraid of criticism about script security, programming style, or which editor you use to create them. You don’t need to be a programmer or even a Linux expert to create some pretty cool scripts. All you really must do is test your scripts, document your scripts, and give your scripts descriptive names.
Test your scripts to make sure they work like you expect them to. Document your scripts inside and outside the script so that you don’t forget what the script’s original purpose is and that anyone else using the script will know how to use it. Name your scripts such that its functionality is at least hinted at from the name.
Those of you who are new to Linux might ask, “Why do I need to create scripts?” The answer is simple, you don’t need to but once you’re worn out from typing the same commands several times per day, you’ll want to create them.
Scripts help you manage your system(s) more efficiently. And, the rule of thumb is, that if you’re typing it, you can script it.
I only use the Bourne-Again Shell (BASH)* for scripting. It’s the default shell in Linux and it has the best features from the other major shells. But don’t worry if you don’t use BASH, you can still write scripts that use BASH, even if you use a different user shell. The prerequisites for gaining the most out of this series are that you know how to use basic shell commands. For example, cd, ls, ps, cat, chmod and a command line text editor such as vi, emacs, or nano.
I only use the vi** editor in the examples.
This series is interactive, so you’ll need access to a Linux system, physical or virtual, with which to work. If you’re required to use root user privileges or sudo access, I’ll note that in the example.
At the Command Line
To keep my scripts in this separate from everything else, I created an area in my home directory for them under scripts/intro. Shell scripts are simply commands contained in a file (a shell script file) that run as if you had run them individually at the command line. Enough introduction, let’s get started with some shell scripts.
Open your favorite text editor and enter some commands into it on a one command per line basis. To run the script within a BASH shell, enter #!/bin/bash.
This line, which must be the first line in your script, is the only line that may begin with the # (shell) symbol. Placed anywhere else in the script and the shell interpreter ignores it and anything on the line after it. This is the comment symbol everywhere but on the first line. Continue by adding some commands as shown.
Save the file with a descriptive name (no spaces) and with a .sh at the end of the name. For example, file_create.sh. The file is simply a text file, not a script at this point. Do you know why? It’s because the file permissions don’t allow execution. To change the behavior, enter the following command:
$ chmod +x file_create.sh
Now, execute the file and allow it to create the two files and display their contents.
As demonstrated in the script, you can enter as many commands as you want into a script. They will execute one after the other, from top to bottom, until the script completes.
For a practical application of the script you created, try this one that checks the lastlog and then mails you the list of user who’ve logged in during the current month.
echo $HOSTNAME > logins.txt
echo " " >> logins.txt
last >> logins.txt
mail email@example.com < logins.txt
Note that this file records the hostname to help you identify which hosts your messages originate from, in case you have more than one that you manage.
What if you need more flexibility in your scripts that you just can't program to run autonomously? You program them to run interactively and provide the intelligence as needs and circumstances change.
This script prompts you for a filename, some initial content for the file, and then writes the provided information to the specified filename.
echo "Enter the name of the file you wish to create."
echo "Enter any info you want to enter into the file."
echo $INFO >> $FILENAME
Grant execute permission to the file and run it. Does it produce the expected results? Do you see any other useful applications for the scripts you've learned today? How about interactively adding information into a database?
Next week, you'll gain considerably more experience writing scripts now that all of the trivia and introductory material is out of the way. If you have particular problems you'd like to solve, use the Comments section to address them. Other readers might have some good ideas or I can tackle them in upcoming posts. Try out a few scripts on your own from the ones you've learned here and post them for others to use.
Remember, that we're an interactive, positive community that wants to foster open communications. Everyone comes in from a different place and it's our job to nurture learning and discovery. Until next week, happy scripting!
* Watch for my upcoming, Korn Shell tale post.
** It's the first one I learned from old UNIX nerds who thought that vi is the only editor. What can I say?
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62