tr [-c | -C][-s] string1 string2
tr -s [-c | -C] string1
tr -d [-c | -C] string1
tr -ds [-c | -C] string1 string2
The tr utility shall copy the standard input to the standard output with substitution or deletion of selected characters. The options specified and the string1 and string2 operands shall control translations that occur while copying characters and single-character collating elements.
The tr utility shall conform to the Base Definitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.
The following options shall be supported:
The following operands shall be supported:
Translation control strings. Each string shall represent a set of characters to be converted into an array of characters used for the translation. For a detailed description of how the strings are interpreted, see the EXTENDED DESCRIPTION section.
The standard input can be any type of file.
The following environment variables shall affect the execution of tr:
Determine the locale for the behavior of range expressions and equivalence classes.
The tr output shall be identical to the input, with the exception of the specified transformations.
The standard error shall be used only for diagnostic messages.
The operands string1 and string2 (if specified) define two arrays of characters. The constructs in the following list can be used to specify characters or single-character collating elements. If any of the constructs result in multi-character collating elements, tr shall exclude, without a diagnostic, those multi-character elements from the resulting array.
If either or both of the range endpoints are octal sequences of the form \octal, this shall represent the range of specific coded values between the two range endpoints, inclusive.
| alnum | blank | digit | lower | punct | upper | |||
| alpha | cntrl | graph | space | xdigit |
In addition, character class expressions of the form [: name:] shall be recognized in those locales where the name keyword has been given a charclass definition in the LC_CTYPE category.
When both the -d and -s options are specified, any of the character class names shall be accepted in string2. Otherwise, only character class names lower or upper are valid in string2 and then only if the corresponding character class ( upper and lower, respectively) is specified in the same relative position in string1. Such a specification shall be interpreted as a request for case conversion. When [: lower:] appears in string1 and [: upper:] appears in string2, the arrays shall contain the characters from the toupper mapping in the LC_CTYPE category of the current locale. When [: upper:] appears in string1 and [: lower:] appears in string2, the arrays shall contain the characters from the tolower mapping in the LC_CTYPE category of the current locale. The first character from each mapping pair shall be in the array for string1 and the second character from each mapping pair shall be in the array for string2 in the same relative position.
Except for case conversion, the characters specified by a character class expression shall be placed in the array in an unspecified order.
If the name specified for class does not define a valid character class in the current locale, the behavior is undefined.
When the -d option is not specified:
When the -d option is specified:
When the -s option is specified, after any deletions or translations have taken place, repeated sequences of the same character shall be replaced by one occurrence of the same character, if the character is found in the array specified by the last operand. If the last operand contains a character class, such as the following example:
tr -s '[:space:]'
the last operand's array shall contain all of the characters in that character class. However, in a case conversion, as described previously, such as:
tr -s '[:upper:]' '[:lower:]'
the last operand's array shall contain only those characters defined as the second characters in each of the toupper or tolower character pairs, as appropriate.
An empty string used for string1 or string2 produces undefined results.
The following exit values shall be returned:
Default.
The following sections are informative.
If necessary, string1 and string2 can be quoted to avoid pattern matching by the shell.
If an ordinary digit (representing itself) is to follow an octal sequence, the octal sequence must use the full three digits to avoid ambiguity.
When string2 is shorter than string1, a difference results between historical System V and BSD systems. A BSD system pads string2 with the last character found in string2. Thus, it is possible to do the following:
tr 0123456789 d
which would translate all digits to the letter 'd' . Since this area is specifically unspecified in this volume of IEEE Std 1003.1-2001, both the BSD and System V behaviors are allowed, but a conforming application cannot rely on the BSD behavior. It would have to code the example in the following way:
tr 0123456789 '[d*]'
It should be noted that, despite similarities in appearance, the string operands used by tr are not regular expressions.
Unlike some historical implementations, this definition of the tr utility correctly processes NUL characters in its input stream. NUL characters can be stripped by using:
tr -d '\000'
tr -cs "[:alpha:]" "[\n*]" <file1 >file2
tr "[:lower:]" "[:upper:]" <file1
tr "[=e=]" e <file1 >file2
In some early proposals, an explicit option -n was added to disable the historical behavior of stripping NUL characters from the input. It was considered that automatically stripping NUL characters from the input was not correct functionality. However, the removal of -n in a later proposal does not remove the requirement that tr correctly process NUL characters in its input stream. NUL characters can be stripped by using tr -d '\000'.
Historical implementations of tr differ widely in syntax and behavior. For example, the BSD version has not needed the bracket characters for the repetition sequence. The tr utility syntax is based more closely on the System V and XPG3 model while attempting to accommodate historical BSD implementations. In the case of the short string2 padding, the decision was to unspecify the behavior and preserve System V and XPG3 scripts, which might find difficulty with the BSD method. The assumption was made that BSD users of tr have to make accommodations to meet the syntax defined here. Since it is possible to use the repetition sequence to duplicate the desired behavior, whereas there is no simple way to achieve the System V method, this was the correct, if not desirable, approach.
The use of octal values to specify control characters, while having historical precedents, is not portable. The introduction of escape sequences for control characters should provide the necessary portability. It is recognized that this may cause some historical scripts to break.
An early proposal included support for multi-character collating elements. It was pointed out that, while tr does employ some syntactical elements from REs, the aim of tr is quite different; ranges, for example, do not have a similar meaning (``any of the chars in the range matches", versus "translate each character in the range to the output counterpart"). As a result, the previously included support for multi-character collating elements has been removed. What remains are ranges in current collation order (to support, for example, accented characters), character classes, and equivalence classes.
In XPG3 the [: class:] and [= equiv=] conventions are shown with double brackets, as in RE syntax. However, tr does not implement RE principles; it just borrows part of the syntax. Consequently, [: class:] and [= equiv=] should be regarded as syntactical elements on a par with [ x* n], which is not an RE bracket expression.
The standard developers will consider changes to tr that allow it to translate characters between different character encodings, or they will consider providing a new utility to accomplish this.
On historical System V systems, a range expression requires enclosing square-brackets, such as:
tr '[a-z]' '[A-Z]'
However, BSD-based systems did not require the brackets, and this convention is used here to avoid breaking large numbers of BSD scripts:
tr a-z A-Z
The preceding System V script will continue to work because the brackets, treated as regular characters, are translated to themselves. However, any System V script that relied on "a-z" representing the three characters 'a' , '-' , and 'z' have to be rewritten as "az-" .
The ISO POSIX-2:1993 standard had a -c option that behaved similarly to the -C option, but did not supply functionality equivalent to the -c option specified in IEEE Std 1003.1-2001. This meant that historical practice of being able to specify tr -d\200-\377 (which would delete all bytes with the top bit set) would have no effect because, in the C locale, bytes with the values octal 200 to octal 377 are not characters.
The earlier version also said that octal sequences referred to collating elements and could be placed adjacent to each other to specify multi-byte characters. However, it was noted that this caused ambiguities because tr would not be able to tell whether adjacent octal sequences were intending to specify multi-byte characters or multiple single byte characters. IEEE Std 1003.1-2001 specifies that octal sequences always refer to single byte binary values.