Classic Shell Scripting - Arnold Robbins [25]
The wide variations in locale support, and the lack of standardized locale names, make it hard to do much with locales in portable shell scripts, other than force the traditional locale by setting LC_ALL to C. We do that in some of the scripts in this book when locale dependence could otherwise produce unexpected results.
* * *
[8] Available at http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt.
[9] Available at http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html.
[10] MB = megabyte, approximately 1 million bytes, where one byte is now conventionally eight bits (binary digits), although both larger and smaller byte sizes have been used in the past. Despite the metric prefix, in computer use, M usually means 220 = 1,048,576.
[11] Available at ftp://ftp.gnu.org/gnu/gettext/.
Summary
The choice of compiled language versus scripting language is usually made based on the need of the application. Scripting languages generally work at a higher level than compiled languages, and the loss in performance is often more than made up for by the speed with which development can be done and the ability to work at a higher level.
The shell is one of the most important and widely used scripting languages in the Unix environment. Because it is ubiquitous, and because of the POSIX standard, it is possible to write shell programs that will work on many different vendor platforms. Because the shell functions at a high level, shell programs have a lot of bang for the buck; you can do a lot with relatively little work.
The #! first line should be used for all shell scripts; this mechanism provides you with flexibility, and the ability to write scripts in your choice of shell or other language.
The shell is a full programming language. So far we covered the basics of commands, options, arguments, and variables, and basic output with echo and printf. We also looked at the basic I/O redirection operators, <, >, >>, and |, with which we expect you're really already familiar.
The shell looks for commands in each directory in $PATH. It's common to have a personal bin directory in which to store your own private programs and scripts, and to list it in PATH by doing an assignment in your .profile file.
We looked at the basics of accessing command-line arguments and simple execution tracing.
Finally, we discussed internationalization and localization, topics that are growing in importance as computer systems are adapted to the computing needs of more of the world's people. While support in this area for shell scripts is still limited, shell programmers need to be aware of the influence of locales on their code.
Chapter 3. Searching and Substitutions
As we discussed in Section 1.2, Unix programmers prefer to work on lines of text. Textual data is more flexible than binary data, and Unix systems provide a number of tools that make slicing and dicing text easy.
In this chapter, we look at two fundamental operations that show up repeatedly in shell scripting: text searching—looking for specific lines of text—and text substitution—changing the text that is found.
While you can accomplish many things by using simple constant text strings, regular expressions provide a much more powerful notation for matching many different actual text fragments with a single expression. This chapter introduces the two regular expression "flavors" provided by various Unix programs, and then proceeds to cover the most important tools for text extraction and rearranging.
Searching for Text
The workhorse program for finding text (or "matching text," in Unix jargon) is grep. On POSIX systems, grep can use either of the two regular expression flavors, or match simple strings.
Traditionally, there were three separate programs for searching through text files:
grep
The original text-matching program. It uses Basic Regular Expressions (BREs) as defined by POSIX, and as we describe later in the chapter.
egrep
"Extended