1TR(1P) POSIX Programmer's Manual TR(1P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 tr - translate characters
13
15 tr [-c | -C][-s] string1 string2
16 tr -s [-c | -C] string1
18 tr -d [-c | -C] string1
20 tr -ds [-c | -C] string1 string2
22
25 The tr utility shall copy the standard input to the standard output
26 with substitution or deletion of selected characters. The options
27 specified and the string1 and string2 operands shall control transla‐
28 tions that occur while copying characters and single-character collat‐
29 ing elements.
30
32 The tr utility shall conform to the Base Definitions volume of
33 IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.
34 The following options shall be supported:
36 -c Complement the set of values specified by string1. See the
38 EXTENDED DESCRIPTION section.
39 -C Complement the set of characters specified by string1. See the
41 EXTENDED DESCRIPTION section.
42 -d Delete all occurrences of input characters that are specified by
44 string1.
45 -s Replace instances of repeated characters with a single charac‐
47 ter, as described in the EXTENDED DESCRIPTION section.
48
51 The following operands shall be supported:
52 string1, string2
54 Translation control strings. Each string shall represent a set
56 of characters to be converted into an array of characters used
57 for the translation. For a detailed description of how the
58 strings are interpreted, see the EXTENDED DESCRIPTION section.
59
62 The standard input can be any type of file.
63
65 None.
66
68 The following environment variables shall affect the execution of tr:
69 LANG Provide a default value for the internationalization variables
71 that are unset or null. (See the Base Definitions volume of
72 IEEE Std 1003.1-2001, Section 8.2, Internationalization Vari‐
73 ables for the precedence of internationalization variables used
74 to determine the values of locale categories.)
75 LC_ALL If set to a non-empty string value, override the values of all
77 the other internationalization variables.
78 LC_COLLATE
80 Determine the locale for the behavior of range expressions and
82 equivalence classes.
83 LC_CTYPE
85 Determine the locale for the interpretation of sequences of
86 bytes of text data as characters (for example, single-byte as
87 opposed to multi-byte characters in arguments) and the behavior
88 of character classes.
89 LC_MESSAGES
91 Determine the locale that should be used to affect the format
92 and contents of diagnostic messages written to standard error.
93 NLSPATH
95 Determine the location of message catalogs for the processing of
96 LC_MESSAGES .
97
100 Default.
101
103 The tr output shall be identical to the input, with the exception of
104 the specified transformations.
105
107 The standard error shall be used only for diagnostic messages.
108
110 None.
111
113 The operands string1 and string2 (if specified) define two arrays of
114 characters. The constructs in the following list can be used to specify
115 characters or single-character collating elements. If any of the con‐
116 structs result in multi-character collating elements, tr shall exclude,
117 without a diagnostic, those multi-character elements from the resulting
118 array.
119 character
121 Any character not described by one of the conventions below
122 shall represent itself.
123 \octal Octal sequences can be used to represent characters with spe‐
125 cific coded values. An octal sequence shall consist of a back‐
126 slash followed by the longest sequence of one, two, or three-
127 octal-digit characters (01234567). The sequence shall cause the
128 value whose encoding is represented by the one, two, or three-
129 digit octal integer to be placed into the array. If the size of
130 a byte on the system is greater than nine bits, the valid escape
131 sequence used to represent a byte is implementation-defined.
132 Multi-byte characters require multiple, concatenated escape
133 sequences of this type, including the leading '\' for each byte.
134 \character
136 The backslash-escape sequences in the Base Definitions volume of
137 IEEE Std 1003.1-2001, Table 5-1, Escape Sequences and Associated
138 Actions ( '\\', '\a', '\b', '\f', '\n', '\r', '\t', '\v' ) shall
139 be supported. The results of using any other character, other
140 than an octal digit, following the backslash are unspecified.
141 c-c In the POSIX locale, this construct shall represent the range of
143 collating elements between the range endpoints (as long as nei‐
144 ther endpoint is an octal sequence of the form \octal), inclu‐
145 sive, as defined by the collation sequence. The characters or
146 collating elements in the range shall be placed in the array in
147 ascending collation sequence. If the second endpoint precedes
148 the starting endpoint in the collation sequence, it is unspeci‐
149 fied whether the range of collating elements is empty, or this
150 construct is treated as invalid. In locales other than the POSIX
151 locale, this construct has unspecified behavior.
152 If either or both of the range endpoints are octal sequences of the
154 form \octal, this shall represent the range of specific coded values
155 between the two range endpoints, inclusive.
156 :class:
158 Represents all characters belonging to the defined character
159 class, as defined by the current setting of the LC_CTYPE locale
160 category. The following character class names shall be accepted
161 when specified in string1:
162 alnum blank digit lower punct upper
164 alpha cntrl graph print space xdigit
165 In addition, character class expressions of the form [: name:] shall be
167 recognized in those locales where the name keyword has been given a
168 charclass definition in the LC_CTYPE category.
169 When both the -d and -s options are specified, any of the character
171 class names shall be accepted in string2. Otherwise, only character
172 class names lower or upper are valid in string2 and then only if the
173 corresponding character class ( upper and lower, respectively) is spec‐
174 ified in the same relative position in string1. Such a specification
175 shall be interpreted as a request for case conversion. When [: lower:]
176 appears in string1 and [: upper:] appears in string2, the arrays shall
177 contain the characters from the toupper mapping in the LC_CTYPE cate‐
178 gory of the current locale. When [: upper:] appears in string1 and [:
179 lower:] appears in string2, the arrays shall contain the characters
180 from the tolower mapping in the LC_CTYPE category of the current
181 locale. The first character from each mapping pair shall be in the
182 array for string1 and the second character from each mapping pair shall
183 be in the array for string2 in the same relative position.
184 Except for case conversion, the characters specified by a character
186 class expression shall be placed in the array in an unspecified order.
187 If the name specified for class does not define a valid character class
189 in the current locale, the behavior is undefined.
190 =equiv=
192 Represents all characters or collating elements belonging to the
193 same equivalence class as equiv, as defined by the current set‐
194 ting of the LC_COLLATE locale category. An equivalence class
195 expression shall be allowed only in string1, or in string2 when
196 it is being used by the combined -d and -s options. The charac‐
197 ters belonging to the equivalence class shall be placed in the
198 array in an unspecified order.
199 x*n Represents n repeated occurrences of the character x. Because
201 this expression is used to map multiple characters to one, it is
202 only valid when it occurs in string2. If n is omitted or is
203 zero, it shall be interpreted as large enough to extend the
204 string2-based sequence to the length of the string1-based
205 sequence. If n has a leading zero, it shall be interpreted as an
206 octal value. Otherwise, it shall be interpreted as a decimal
207 value.
208 When the -d option is not specified:
211 * Each input character found in the array specified by string1 shall
213 be replaced by the character in the same relative position in the
214 array specified by string2. When the array specified by string2 is
215 shorter that the one specified by string1, the results are unspeci‐
216 fied.
217 * If the -C option is specified, the complements of the characters
219 specified by string1 (the set of all characters in the current char‐
220 acter set, as defined by the current setting of LC_CTYPE, except
221 for those actually specified in the string1 operand) shall be placed
222 in the array in ascending collation sequence, as defined by the cur‐
223 rent setting of LC_COLLATE.
224 * If the -c option is specified, the complement of the values speci‐
226 fied by string1 shall be placed in the array in ascending order by
227 binary value.
228 * Because the order in which characters specified by character class
230 expressions or equivalence class expressions is undefined, such
231 expressions should only be used if the intent is to map several
232 characters into one. An exception is case conversion, as described
233 previously.
234 When the -d option is specified:
236 * Input characters found in the array specified by string1 shall be
238 deleted.
239 * When the -C option is specified with -d, all characters except those
241 specified by string1 shall be deleted. The contents of string2 are
242 ignored, unless the -s option is also specified.
243 * When the -c option is specified with -d, all values except those
245 specified by string1 shall be deleted. The contents of string2 shall
246 be ignored, unless the -s option is also specified.
247 * The same string cannot be used for both the -d and the -s option;
249 when both options are specified, both string1 (used for deletion)
250 and string2 (used for squeezing) shall be required.
251 When the -s option is specified, after any deletions or translations
253 have taken place, repeated sequences of the same character shall be
254 replaced by one occurrence of the same character, if the character is
255 found in the array specified by the last operand. If the last operand
256 contains a character class, such as the following example:
257 tr -s '[:space:]'
260 the last operand's array shall contain all of the characters in that
262 character class. However, in a case conversion, as described previ‐
263 ously, such as:
264 tr -s '[:upper:]' '[:lower:]'
267 the last operand's array shall contain only those characters defined as
269 the second characters in each of the toupper or tolower character
270 pairs, as appropriate.
271 An empty string used for string1 or string2 produces undefined results.
273
275 The following exit values shall be returned:
276 0 All input was processed successfully.
278 >0 An error occurred.
280
283 Default.
284 The following sections are informative.
286
288 If necessary, string1 and string2 can be quoted to avoid pattern match‐
289 ing by the shell.
290 If an ordinary digit (representing itself) is to follow an octal
292 sequence, the octal sequence must use the full three digits to avoid
293 ambiguity.
294 When string2 is shorter than string1, a difference results between his‐
296 torical System V and BSD systems. A BSD system pads string2 with the
297 last character found in string2. Thus, it is possible to do the fol‐
298 lowing:
299 tr 0123456789 d
302 which would translate all digits to the letter 'd' . Since this area is
304 specifically unspecified in this volume of IEEE Std 1003.1-2001, both
305 the BSD and System V behaviors are allowed, but a conforming applica‐
306 tion cannot rely on the BSD behavior. It would have to code the example
307 in the following way:
308 tr 0123456789 '[d*]'
311 It should be noted that, despite similarities in appearance, the string
313 operands used by tr are not regular expressions.
314 Unlike some historical implementations, this definition of the tr util‐
316 ity correctly processes NUL characters in its input stream. NUL charac‐
317 ters can be stripped by using:
318 tr -d '\000'
321
323 1. The following example creates a list of all words in file1 one per
324 line in file2, where a word is taken to be a maximal string of let‐
325 ters.
326 tr -cs "[:alpha:]" "[\n*]" <file1 >file2
329 2. The next example translates all lowercase characters in file1 to
331 uppercase and writes the results to standard output.
332 tr "[:lower:]" "[:upper:]" <file1
335 3. This example uses an equivalence class to identify accented vari‐
337 ants of the base character 'e' in file1, which are stripped of dia‐
338 critical marks and written to file2.
339 tr "[=e=]" e <file1 >file2
342
344 In some early proposals, an explicit option -n was added to disable the
345 historical behavior of stripping NUL characters from the input. It was
346 considered that automatically stripping NUL characters from the input
347 was not correct functionality. However, the removal of -n in a later
348 proposal does not remove the requirement that tr correctly process NUL
349 characters in its input stream. NUL characters can be stripped by using
350 tr -d '\000'.
351 Historical implementations of tr differ widely in syntax and behavior.
353 For example, the BSD version has not needed the bracket characters for
354 the repetition sequence. The tr utility syntax is based more closely on
355 the System V and XPG3 model while attempting to accommodate historical
356 BSD implementations. In the case of the short string2 padding, the
357 decision was to unspecify the behavior and preserve System V and XPG3
358 scripts, which might find difficulty with the BSD method. The assump‐
359 tion was made that BSD users of tr have to make accommodations to meet
360 the syntax defined here. Since it is possible to use the repetition
361 sequence to duplicate the desired behavior, whereas there is no simple
362 way to achieve the System V method, this was the correct, if not desir‐
363 able, approach.
364 The use of octal values to specify control characters, while having
366 historical precedents, is not portable. The introduction of escape
367 sequences for control characters should provide the necessary portabil‐
368 ity. It is recognized that this may cause some historical scripts to
369 break.
370 An early proposal included support for multi-character collating ele‐
372 ments. It was pointed out that, while tr does employ some syntactical
373 elements from REs, the aim of tr is quite different; ranges, for exam‐
374 ple, do not have a similar meaning (``any of the chars in the range
375 matches", versus "translate each character in the range to the output
376 counterpart"). As a result, the previously included support for multi-
377 character collating elements has been removed. What remains are ranges
378 in current collation order (to support, for example, accented charac‐
379 ters), character classes, and equivalence classes.
380 In XPG3 the [: class:] and [= equiv=] conventions are shown with double
382 brackets, as in RE syntax. However, tr does not implement RE princi‐
383 ples; it just borrows part of the syntax. Consequently, [: class:] and
384 [= equiv=] should be regarded as syntactical elements on a par with [
385 x* n], which is not an RE bracket expression.
386 The standard developers will consider changes to tr that allow it to
388 translate characters between different character encodings, or they
389 will consider providing a new utility to accomplish this.
390 On historical System V systems, a range expression requires enclosing
392 square-brackets, such as:
393 tr '[a-z]' '[A-Z]'
396 However, BSD-based systems did not require the brackets, and this con‐
398 vention is used here to avoid breaking large numbers of BSD scripts:
399 tr a-z A-Z
402 The preceding System V script will continue to work because the brack‐
404 ets, treated as regular characters, are translated to themselves. How‐
405 ever, any System V script that relied on "a-z" representing the three
406 characters 'a', '-', and 'z' have to be rewritten as "az-" .
407 The ISO POSIX-2:1993 standard had a -c option that behaved similarly to
409 the -C option, but did not supply functionality equivalent to the -c
410 option specified in IEEE Std 1003.1-2001. This meant that historical
411 practice of being able to specify tr -d\200-\377 (which would delete
412 all bytes with the top bit set) would have no effect because, in the C
413 locale, bytes with the values octal 200 to octal 377 are not charac‐
414 ters.
415 The earlier version also said that octal sequences referred to collat‐
417 ing elements and could be placed adjacent to each other to specify
418 multi-byte characters. However, it was noted that this caused ambigui‐
419 ties because tr would not be able to tell whether adjacent octal
420 sequences were intending to specify multi-byte characters or multiple
421 single byte characters. IEEE Std 1003.1-2001 specifies that octal
422 sequences always refer to single byte binary values.
423
425 None.
426
428 sed
429
431 Portions of this text are reprinted and reproduced in electronic form
432 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
433 -- Portable Operating System Interface (POSIX), The Open Group Base
434 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
435 Electrical and Electronics Engineers, Inc and The Open Group. In the
436 event of any discrepancy between this version and the original IEEE and
437 The Open Group Standard, the original IEEE and The Open Group Standard
438 is the referee document. The original Standard can be obtained online
439 at http://www.opengroup.org/unix/online.html .
440IEEE/The Open Group 2003 TR(1P)