TR(1) General Commands Manual TR(1)

tr — translate characters

tr [-cs] string1 string2

tr -s [-c] string1

tr -d [-c] string1

tr -ds [-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 collating elements.

The tr utility shall conform to the utility argument syntax guidelines described in 2.10.2. The following options shall be supported by the implementation:

Complement the set of characters specified by string1. See EXTENDED DESCRIPTION .

Delete all occurrences of input characters that are specified by string1.

Replace instances of repeated characters with a single character, as described in EXTENDED DESCRIPTION .

The following operands shall be supported by the implementation: string1

string2

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 EXTENDED DESCRIPTION .

The standard input can be any type of file.

None.

The following environment variables shall affect the execution of tr:

This variable shall determine the locale to use for the locale categories when both LC_ALL and the corresponding environment variable (beginning with LC_ ) do not specify a locale. See 2.6.

This variable shall determine the locale to be used to override any values for locale categories specified by the settings of LANG or any environment variables beginning with LC_.

This variable shall determine the behavior of range expressions and equivalence classes.

This variable shall determine the locale for the interpretation of sequences of bytes of text data as characters (e.g., single- versus multibyte characters in arguments) and the behavior of character classes.

This variable shall determine the language in which messages should be written.

Default.

The tr output shall be identical to the input, with the exception of the specified transformations.

Used only for diagnostic messages.

None.

The operands string1 and string2 (if specified) define two arrays of characters or collating elements. The following conventions can be used to specify characters or collating elements: character Any character not described by one of the conventions below shall represent itself. \octal Octal sequences can be used to represent characters with specific coded values. An octal sequence shall consist of a backslash followed by the longest sequence of one-, two-, or three-octal-digit characters (01234567). The sequence shall cause the character whose encoding is represented by the one-, two-, or three-digit octal integer to be placed into the array. If the size of a byte on the system is greater than nine bits, the valid escape sequence used to represent a byte is implementation-defined. Multibyte characters require multiple, concatenated escape sequences of this type, including the leading \ for each byte.

\character The backslash-escape sequences in Table 2-15 (see 2.12) shall be supported. The results of using any other character, other than an octal digit, following the backslash are unspecified. c−c Represents the range of collating elements between the range endpoints, inclusive, as defined by the current setting of the LC_COLLATE locale category. The starting endpoint shall precede the second endpoint in the current collation order. The characters or collating elements in the range shall be placed in the array in ascending collation sequence. No multicharacter collating elements shall be included in the range. [:class:] Represents all characters belonging to the defined character class, as defined by the current setting of the LC_CTYPE locale

category. The following character class names shall be accepted when specified in string1:

alnum cntrl lower space alpha digit print upper blank graph punct xdigit

When the −d and −s options are specified together, any of the character class names shall be accepted in string2. Otherwise, only character class names lower or upper shall be accepted 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. [=equiv=] Represents all characters or collating elements belonging to the same equivalence class as equiv, as defined by the current setting of the LC_COLLATE locale category. An equivalence class expression shall be allowed only in string1, or in string2 when it is being used by the combined −d and −s options. The characters belonging to the equivalence class shall be placed in the array in an unspecified order. [x∗n] Represents n repeated occurrences of the character or collating symbol x. Because this expression is used to map multiple characters to one, it is only valid when it occurs in string2. If n is omitted or is zero, it shall be interpreted as large enough to extend the string2-based sequence to the length of the string1- based sequence. If n has a leading zero, it shall be interpreted as an octal value. Otherwise, it shall be interpreted as a decimal value.

When the −d option is not specified:

  • Each input character or collating element found in the array specified by string1 shall be replaced by the character or collating element in the same relative position in the array specified by string2. When the array specified by string2 is shorter that the one specified by string1, the results are unspecified.
  • If the −c option is specified without −d, the complement of the characters specified by string1—the set of all characters in the current character set, as defined by the current setting of LC_CTYPE, except for those actually specified in the string1 operand—shall be placed in the array in ascending collation sequence, as defined by the current setting of LC_COLLATE.
  • Because the order in which characters specified by character class expressions or equivalence class expressions is undefined, such expressions should only be used if the intent is to map several characters into one. An exception is case conversion, as described previously.

When the −d option is specified:

  • Input characters or collating elements found in the array specified by string1 shall be deleted.
  • When the −c option is specified with −d, all characters except those specified by string1 shall be deleted. The contents of string2 shall be ignored, unless the −s option is also specified.
  • The same string cannot be used for both the −d and the −s option; when both options are specified, both string1 (used for deletion) and string2 (used for squeezing) shall be required.

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.

The tr utility shall exit with one of the following values:

All input was processed successfully.

An error occurred.

Default.

If necessary, string1 and string2 can be quoted to avoid pattern matching by the shell. The following example creates a list of all words in file1 one per line in file2, where a word is taken to be a maximal string of letters. tr -cs "[:alpha:]" "[\n∗]" <file1 >file2 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 will pad 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 the standard, 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. On historical System V systems, a range expression requires enclosing squarebrackets, such as:

tr ’[a-z]’ ’[A-Z]’

However, BSD -based systems did not require the brackets and this convention is used by POSIX. 2 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 will have to be rewritten as az- or a\-z.

In some earlier drafts, an explicit option, −n, was added to disable the historical behavior of stripping NUL characters from the input. It was felt that automatically stripping NUL characters from the input was not correct functionality. However, the removal of −n in a later draft 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 POSIX. 2 tr 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 scripts, which might find difficulty with the BSD method. The assumption was made that BSD users of tr will have to make accommodations to meet the POSIX. 2 syntax anyway, and 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. A previous draft included support for multicharacter collating elements. Several balloters pointed out that, while tr does employ some syntactical elements from regular expressions, the aim of tr is quite different; ranges, for instance, do not mean the same thing (‘‘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 multicharacter collating elements has been removed. What remains are ranges in current collation order (to support, e.g., accented characters), character classes, and equivalence classes. In XPG3, the [:class:] and [=equiv=] conventions are shown with double brackets, as in regular expression syntax. Several balloters objected to this, pointing out that tr does not implement regular expression principles, just borrows part of the syntax. Consequently, the [:class:] and [=equiv=] should be regarded as syntactical elements on a par with [x∗n], which is not an RE bracket expression.

September 1991 posix.fail