Product SiteDocumentation Site

Chapter 14. Automating RPM with Scripts

14.1. Scripting
14.2. Distinguishing Scripting Languages from Programming Languages
14.3. Deciding When to Program and When to Script
14.4. Shell Scripting Basics
14.4.1. Writing a script
14.4.2. Running a script
14.4.3. Problems running scripts
14.4.4. Turning a script into a command
14.4.5. Passing command-line options to your script
14.5. Examining RPM Files
14.6. Querying the RPM Database
14.6.1. Querying for all packages installed at the same time
14.6.2. Reading HTML documentation for a package
14.7. Where to Go From Here
14.8. Summary
This chapter covers:
The rpm command provides a very high-level view of package management. Most of the operations you need to perform require only a single invocation. Some of the command-line options to the rpm command tend to get very complex, however, especially for detailed queries. That’s where scripting can help.
This chapter covers scripting, specifically shell scripting, with the rpm command, especially for newcomers to Linux scripting

14.1. Scripting

Scripting allows you to quickly write new commands in a language, called a scripting language, that can help automate your work. Used heavily by system administrators and lightly by software developers, scripts can help remove some of the tedium from your day-to-day tasks. Scripts can also hold the complex query formats used with the rpm command so you don’t have to remember them.
Scripts start out as text files. These text files hold commands in the scripting language. Most of these script file commands run commands installed on your system, such as rpm. To run a script, invoke a command, called an interpreter, that reads in the script file and executes the commands inside the script.
Programming is usually considered different from scripting, even though there are many similarities. Programs start out as text files. These text files hold commands in the programming language and sometimes, not often, calls to commands installed on your system. Programs generally involve more work than scripts and are generally larger, containing more commands.
Furthermore, most programs need to be compiled. A separate command parses the program text files and generates some form of machine code. Multiple pieces of a program may be linked together to form a command you can call from your shell prompt.
Some programming languages, such as Java or C#, are compiled to a generic bytecode format. A compiled Java program, for example, is the same no matter what the architecture. To run such a program, you need a runtime engine such as the java command provides. (Runtime engine is a fancy term for interpreter.)
Such differences between scripting and programming sometimes get in the way of performing real work. For example, I once worked with a group of people who were convinced that they were not programmers. They felt that programming was an art that was far beyond them. Yet, they wrote hundreds of kilobytes of scripts to create a sophisticated graphical interface for a Computer-Aided Design system. In my mind, they were programming (and doing quite well at it). In their minds, though, there was a clear distinction between scripting@mdwhat they could do@mdand programming, which was beyond them, they thought.
Don’t get caught up in this. Use the right tool for the job.