TR(1)                      POSIX Programmer's Manual                     TR(1)



PPRROOLLOOGG
       This manual page is part of the POSIX Programmer's Manual.  The OS
       implementation of this interface may differ (consult the corresponding
       OS manual page for details of OS behavior), or the interface may not be
       implemented on OS.


NNAAMMEE
       tr -- translate characters

SSYYNNOOPPSSIISS
       tr [[-c|-C]] [[-s]] _s_t_r_i_n_g_1 _s_t_r_i_n_g_2

       tr -s [[-c|-C]] _s_t_r_i_n_g_1

       tr -d [[-c|-C]] _s_t_r_i_n_g_1

       tr -ds [[-c|-C]] _s_t_r_i_n_g_1 _s_t_r_i_n_g_2

DDEESSCCRRIIPPTTIIOONN
       The _t_r utility shall copy the standard input to the standard output
       with substitution or deletion of selected characters. The options
       specified and the _s_t_r_i_n_g_1 and _s_t_r_i_n_g_2 operands shall control
       translations that occur while copying characters and single-character
       collating elements.

OOPPTTIIOONNSS
       The _t_r utility shall conform to the Base Definitions volume of
       POSIX.1-2008, _S_e_c_t_i_o_n _1_2_._2, _U_t_i_l_i_t_y _S_y_n_t_a_x _G_u_i_d_e_l_i_n_e_s.

       The following options shall be supported:

       --cc        Complement the set of values specified by _s_t_r_i_n_g_1.  See the
                 EXTENDED DESCRIPTION section.

       --CC        Complement the set of characters specified by _s_t_r_i_n_g_1.  See
                 the EXTENDED DESCRIPTION section.

       --dd        Delete all occurrences of input characters that are specified
                 by _s_t_r_i_n_g_1.

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

OOPPEERRAANNDDSS
       The following operands shall be supported:

       _s_t_r_i_n_g_1, _s_t_r_i_n_g_2
                 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.

SSTTDDIINN
       The standard input can be any type of file.

IINNPPUUTT FFIILLEESS
       None.

EENNVVIIRROONNMMEENNTT VVAARRIIAABBLLEESS
       The following environment variables shall affect the execution of _t_r:

       _L_A_N_G      Provide a default value for the internationalization
                 variables that are unset or null. (See the Base Definitions
                 volume of POSIX.1-2008, _S_e_c_t_i_o_n _8_._2, _I_n_t_e_r_n_a_t_i_o_n_a_l_i_z_a_t_i_o_n
                 _V_a_r_i_a_b_l_e_s for the precedence of internationalization
                 variables used to determine the values of locale categories.)

       _L_C___A_L_L    If set to a non-empty string value, override the values of
                 all the other internationalization variables.

       _L_C___C_O_L_L_A_T_E
                 Determine the locale for the behavior of range expressions
                 and equivalence classes.

       _L_C___C_T_Y_P_E  Determine the locale for the interpretation of sequences of
                 bytes of text data as characters (for example, single-byte as
                 opposed to multi-byte characters in arguments) and the
                 behavior of character classes.

       _L_C___M_E_S_S_A_G_E_S
                 Determine the locale that should be used to affect the format
                 and contents of diagnostic messages written to standard
                 error.

       _N_L_S_P_A_T_H   Determine the location of message catalogs for the processing
                 of _L_C___M_E_S_S_A_G_E_S.

AASSYYNNCCHHRROONNOOUUSS EEVVEENNTTSS
       Default.

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

SSTTDDEERRRR
       The standard error shall be used only for diagnostic messages.

OOUUTTPPUUTT FFIILLEESS
       None.

EEXXTTEENNDDEEDD DDEESSCCRRIIPPTTIIOONN
       The operands _s_t_r_i_n_g_1 and _s_t_r_i_n_g_2 (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, _t_r shall
       exclude, without a diagnostic, those multi-character elements from the
       resulting array.

       _c_h_a_r_a_c_t_e_r Any character not described by one of the conventions below
                 shall represent itself.

       \_o_c_t_a_l    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 value whose encoding is represented by the one,
                 two, or three-digit octal integer to be placed into the
                 array. Multi-byte characters require multiple, concatenated
                 escape sequences of this type, including the leading
                 <backslash> for each byte.

       \_c_h_a_r_a_c_t_e_r
                 The <backslash>-escape sequences in the Base Definitions
                 volume of POSIX.1-2008, _T_a_b_l_e _5_-_1, _E_s_c_a_p_e _S_e_q_u_e_n_c_e_s _a_n_d
                 _A_s_s_o_c_i_a_t_e_d _A_c_t_i_o_n_s (''\\\\'', ''\\aa'', ''\\bb'', ''\\ff'', ''\\nn'', ''\\rr'', ''\\tt'',
                 ''\\vv'') shall be supported. The results of using any other
                 character, other than an octal digit, following the
                 <backslash> are unspecified. Also, if there is no character
                 following the <backslash>, the results are unspecified.

       _c-_c       In the POSIX locale, this construct shall represent the range
                 of collating elements between the range endpoints (as long as
                 neither endpoint is an octal sequence of the form \_o_c_t_a_l),
                 inclusive, as defined by the collation sequence. The
                 characters or collating elements in the range shall be placed
                 in the array in ascending collation sequence. If the second
                 endpoint precedes the starting endpoint in the collation
                 sequence, it is unspecified whether the range of collating
                 elements is empty, or this construct is treated as invalid.
                 In locales other than the POSIX locale, this construct has
                 unspecified behavior.

                 If either or both of the range endpoints are octal sequences
                 of the form \_o_c_t_a_l, this shall represent the range of
                 specific coded values between the two range endpoints,
                 inclusive.

       [:_c_l_a_s_s:] Represents all characters belonging to the defined character
                 class, as defined by the current setting of the _L_C___C_T_Y_P_E
                 locale category. The following character class names shall be
                 accepted when specified in _s_t_r_i_n_g_1:

                 aallnnuumm   bbllaannkk   ddiiggiitt   lloowweerr   ppuunncctt   uuppppeerr
                 aallpphhaa   ccnnttrrll   ggrraapphh   pprriinntt   ssppaaccee   xxddiiggiitt

                 In addition, character class expressions of the form [:_n_a_m_e:]
                 shall be recognized in those locales where the _n_a_m_e keyword
                 has been given a cchhaarrccllaassss definition in the _L_C___C_T_Y_P_E
                 category.

                 When both the --dd and --ss options are specified, any of the
                 character class names shall be accepted in _s_t_r_i_n_g_2.
                 Otherwise, only character class names lloowweerr or uuppppeerr are
                 valid in _s_t_r_i_n_g_2 and then only if the corresponding character
                 class (uuppppeerr and lloowweerr, respectively) is specified in the
                 same relative position in _s_t_r_i_n_g_1.  Such a specification
                 shall be interpreted as a request for case conversion. When
                 [:_l_o_w_e_r:] appears in _s_t_r_i_n_g_1 and [:_u_p_p_e_r:] appears in
                 _s_t_r_i_n_g_2, the arrays shall contain the characters from the
                 ttoouuppppeerr mapping in the _L_C___C_T_Y_P_E category of the current
                 locale. When [:_u_p_p_e_r:] appears in _s_t_r_i_n_g_1 and [:_l_o_w_e_r:]
                 appears in _s_t_r_i_n_g_2, the arrays shall contain the characters
                 from the ttoolloowweerr mapping in the _L_C___C_T_Y_P_E category of the
                 current locale. The first character from each mapping pair
                 shall be in the array for _s_t_r_i_n_g_1 and the second character
                 from each mapping pair shall be in the array for _s_t_r_i_n_g_2 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 _c_l_a_s_s does not define a valid
                 character class in the current locale, the behavior is
                 undefined.

       [=_e_q_u_i_v=] Represents all characters or collating elements belonging to
                 the same equivalence class as _e_q_u_i_v, as defined by the
                 current setting of the _L_C___C_O_L_L_A_T_E locale category. An
                 equivalence class expression shall be allowed only in
                 _s_t_r_i_n_g_1, or in _s_t_r_i_n_g_2 when it is being used by the combined
                 --dd and --ss 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 _x.
                 Because this expression is used to map multiple characters to
                 one, it is only valid when it occurs in _s_t_r_i_n_g_2.  If _n is
                 omitted or is zero, it shall be interpreted as large enough
                 to extend the _s_t_r_i_n_g_2-based sequence to the length of the
                 _s_t_r_i_n_g_1-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 --dd option is not specified:

        *  If _s_t_r_i_n_g_2 is present, each input character found in the array
           specified by _s_t_r_i_n_g_1 shall be replaced by the character in the same
           relative position in the array specified by _s_t_r_i_n_g_2.  If the array
           specified by _s_t_r_i_n_g_2 is shorter that the one specified by _s_t_r_i_n_g_1,
           or if a character occurs more than once in _s_t_r_i_n_g_1, the results are
           unspecified.

        *  If the --CC option is specified, the complements of the characters
           specified by _s_t_r_i_n_g_1 (the set of all characters in the current
           character set, as defined by the current setting of _L_C___C_T_Y_P_E,
           except for those actually specified in the _s_t_r_i_n_g_1 operand) shall
           be placed in the array in ascending collation sequence, as defined
           by the current setting of _L_C___C_O_L_L_A_T_E.

        *  If the --cc option is specified, the complement of the values
           specified by _s_t_r_i_n_g_1 shall be placed in the array in ascending
           order by binary value.

        *  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 --dd option is specified:

        *  Input characters found in the array specified by _s_t_r_i_n_g_1 shall be
           deleted.

        *  When the --CC option is specified with --dd, all characters except
           those specified by _s_t_r_i_n_g_1 shall be deleted. The contents of
           _s_t_r_i_n_g_2 are ignored, unless the --ss option is also specified.

        *  When the --cc option is specified with --dd, all values except those
           specified by _s_t_r_i_n_g_1 shall be deleted. The contents of _s_t_r_i_n_g_2
           shall be ignored, unless the --ss option is also specified.

        *  The same string cannot be used for both the --dd and the --ss option;
           when both options are specified, both _s_t_r_i_n_g_1 (used for deletion)
           and _s_t_r_i_n_g_2 (used for squeezing) shall be required.

       When the --ss 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:

           ttrr --ss ''[[::ssppaaccee::]]''

       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:

           ttrr --ss ''[[::uuppppeerr::]]'' ''[[::lloowweerr::]]''

       the last operand's array shall contain only those characters defined as
       the second characters in each of the ttoouuppppeerr or ttoolloowweerr character
       pairs, as appropriate.

       An empty string used for _s_t_r_i_n_g_1 or _s_t_r_i_n_g_2 produces undefined results.

EEXXIITT SSTTAATTUUSS
       The following exit values shall be returned:

        0    All input was processed successfully.

       >0    An error occurred.

CCOONNSSEEQQUUEENNCCEESS OOFF EERRRROORRSS
       Default.

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       If necessary, _s_t_r_i_n_g_1 and _s_t_r_i_n_g_2 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 _s_t_r_i_n_g_2 is shorter than _s_t_r_i_n_g_1, a difference results between
       historical System V and BSD systems. A BSD system pads _s_t_r_i_n_g_2 with the
       last character found in _s_t_r_i_n_g_2.  Thus, it is possible to do the
       following:

           ttrr 00112233445566778899 dd

       which would translate all digits to the letter ''dd''.  Since this area is
       specifically unspecified in this volume of POSIX.1-2008, 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:

           ttrr 00112233445566778899 ''[[dd**]]''

       It should be noted that, despite similarities in appearance, the string
       operands used by _t_r are not regular expressions.

       Unlike some historical implementations, this definition of the _t_r
       utility correctly processes NUL characters in its input stream. NUL
       characters can be stripped by using:

           ttrr --dd ''\\000000''

EEXXAAMMPPLLEESS
        1. The following example creates a list of all words in ffiillee11 one per
           line in ffiillee22, where a word is taken to be a maximal string of
           letters.

               ttrr --ccss ""[[::aallpphhaa::]]"" ""[[\\nn**]]"" <<ffiillee11 >>ffiillee22

        2. The next example translates all lowercase characters in ffiillee11 to
           uppercase and writes the results to standard output.

               ttrr ""[[::lloowweerr::]]"" ""[[::uuppppeerr::]]"" <<ffiillee11

        3. This example uses an equivalence class to identify accented
           variants of the base character ''ee'' in ffiillee11, which are stripped of
           diacritical marks and written to ffiillee22.

               ttrr ""[[==ee==]]"" ""[[ee**]]"" <<ffiillee11 >>ffiillee22

RRAATTIIOONNAALLEE
       In some early proposals, an explicit option --nn 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 --nn in a later
       proposal does not remove the requirement that _t_r correctly process NUL
       characters in its input stream. NUL characters can be stripped by using
       _t_r --dd '\000'.

       Historical implementations of _t_r differ widely in syntax and behavior.
       For example, the BSD version has not needed the bracket characters for
       the repetition sequence. The _t_r 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 _s_t_r_i_n_g_2 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 _t_r 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 _t_r does employ some
       syntactical elements from REs, the aim of _t_r is quite different;
       ranges, for example, do not have a similar meaning (``any of the chars
       in the range matches'', _v_e_r_s_u_s ``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 [:_c_l_a_s_s:] and [=_e_q_u_i_v=] conventions are shown with double
       brackets, as in RE syntax. However, _t_r does not implement RE
       principles; it just borrows part of the syntax.  Consequently,
       [:_c_l_a_s_s:] and [=_e_q_u_i_v=] 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 _t_r 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:

           ttrr ''[[aa--zz]]'' ''[[AA--ZZ]]''

       However, BSD-based systems did not require the brackets, and this
       convention is used here to avoid breaking large numbers of BSD scripts:

           ttrr aa--zz AA--ZZ

       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 ""aa--zz"" representing the
       three characters ''aa'', ''--'', and ''zz'' have to be rewritten as ""aazz--"".

       The ISO POSIX-2:1993 standard had a --cc option that behaved similarly to
       the --CC option, but did not supply functionality equivalent to the --cc
       option specified in POSIX.1-2008. This meant that historical practice
       of being able to specify _t_r --ccdd\000-\177 (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 _t_r would not be able to tell whether adjacent octal
       sequences were intending to specify multi-byte characters or multiple
       single byte characters. POSIX.1-2008 specifies that octal sequences
       always refer to single byte binary values when used to specify an
       endpoint of a range of collating elements.

       Earlier versions of this standard allowed for implementations with
       bytes other than eight bits, but this has been modified in this
       version.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _s_e_d

       The Base Definitions volume of POSIX.1-2008, _T_a_b_l_e _5_-_1, _E_s_c_a_p_e
       _S_e_q_u_e_n_c_e_s _a_n_d _A_s_s_o_c_i_a_t_e_d _A_c_t_i_o_n_s, _C_h_a_p_t_e_r _8, _E_n_v_i_r_o_n_m_e_n_t _V_a_r_i_a_b_l_e_s,
       _S_e_c_t_i_o_n _1_2_._2, _U_t_i_l_i_t_y _S_y_n_t_a_x _G_u_i_d_e_l_i_n_e_s

CCOOPPYYRRIIGGHHTT
       Portions of this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
       -- Portable Operating System Interface (POSIX), The Open Group Base
       Specifications Issue 7, Copyright (C) 2013 by the Institute of
       Electrical and Electronics Engineers, Inc and The Open Group.  (This is
       POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
       event of any discrepancy between this version and the original IEEE and
       The Open Group Standard, the original IEEE and The Open Group Standard
       is the referee document. The original Standard can be obtained online
       at http://www.unix.org/online.html .

       Any typographical or formatting errors that appear in this page are
       most likely to have been introduced during the conversion of the source
       files to man page format. To report such errors, see
       https://www.kernel.org/doc/man-pages/reporting_bugs.html .



IEEE/The Open Group                  2013                                TR(1)
