Classic Shell Scripting - Arnold Robbins [23]
$ cat > trace1.sh
Create script
#! /bin/sh
set -x
Turn on tracing
echo 1st echo
Do something
set +x
Turn off tracing
echo 2nd echo
Do something else
^D
Terminate with end-of-file
$ chmod +x trace1.sh
Make program executable
$ ./trace1.sh
Run it
+ echo 1st echo First traced line
1st echo Output from command
+ set +x Next traced line
2nd echo Output from next command
When run, the set -x is not traced, since tracing isn't turned on until after that command completes. Similarly, the set +x is traced, since tracing isn't turned off until after it completes. The final echo isn't traced, since tracing is turned off at that point.
Internationalization and Localization
Writing software for an international audience is a challenging problem. The task is usually divided into two parts: internationalization (i18n for short, since that long word has 18 letters between the first and last), and localization (similarly abbreviated l10n).
Internationalization is the process of designing software so that it can be adapted for specific user communities without having to change or recompile the code. At a minimum, this means that all character strings must be wrapped in library calls that handle runtime lookup of suitable translations in message catalogs. Typically, the translations are specified in ordinary text files that accompany the software, and then are compiled by gencat or msgfmt into compact binary files organized for fast lookup. The compiled message catalogs are then installed in a system-specific directory tree, such as the GNU conventional /usr/share/locale and /usr/local/share/locale, or on commercial Unix systems, /usr/lib/nls or /usr/lib/locale. Details can be found in the manual pages for setlocale(3), catgets(3C), and gettext(3C).
Localization is the process of adapting internationalized software for use by specific user communities. This may require translating software documentation, and all text strings output by the software, and possibly changing the formats of currency, dates, numbers, times, units of measurement, and so on, in program output. The character set used for text may also have to be changed, unless the universal Unicode character set can be used, and different fonts may be required. For some languages, the writing direction has to be changed as well.
In the Unix world, ISO programming language standards and POSIX have introduced limited support for addressing these problems, but much remains to be done, and progress varies substantially across the various flavors of Unix. For the user, the feature that controls which language or cultural environment is in effect is called the locale, and it is set by one or more of the environment variables shown in Table 2-3.
Table 2-3. Locale environment variables
Name
Description
LANG
Default value for any LC_xxx variable that is not otherwise set
LC_ALL
Value that overrides all other LC_xxx variables
LC_COLLATE
Locale name for collation (sorting)
LC_CTYPE
Locale name for character types (alphabetic, digit, punctuation, and so on)
LC_MESSAGES
Locale name for affirmative and negative responses and for messages; POSIX only
LC_MONETARY
Locale name for currency formatting
LC_NUMERIC
Locale name for number formatting
LC_TIME
Locale name for date and time formatting
In general, you set LC_ALL to force a single locale, and you set LANG to provide a fallback locale. In most cases, you should avoid setting any of the other LC_xxx variables. For example, although it might appear to be more precise to set LC_COLLATE when you use the sort command, that setting might conflict with a setting of LC_CTYPE, or be ignored entirely if LC_ALL is set.
Only a single standard locale name, C, is prescribed by the ISO C and C++ standards: it selects traditional ASCII-oriented behavior. POSIX specifies one additional locale