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

printf — write formatted output

printf format [argument...]

The utility shall write formatted operands to the standard
output. The operands shall be formatted under control of the


The following operands shall be supported:

format    A string describing the format to use to write the
          remaining operands.  See the EXTENDED DESCRIPTION

argument  The strings to be written to standard output,
          under the control of See the EXTENDED DESCRIPTION

Not used.


The following environment variables shall affect the
execution of

LANG      Provide a default value for the
          internationalization variables that are unset or
          null. (See the Base Definitions volume of
          POSIX.1‐2008, the precedence of
          internationalization variables used to determine
          the values of locale categories.)

LC_ALL    If set to a non‐empty string value, override the
          values of all the other internationalization

LC_CTYPE  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).

          Determine the locale that should be used to affect


          the format and contents of diagnostic messages
          written to standard error.

          Determine the locale for numeric formatting. It
          shall affect the format of numbers written using
          the and conversion specifier characters (if

NLSPATH   Determine the location of message catalogs for the
          processing of



The standard error shall be used only for diagnostic


The operand shall be used as the string described in the
Base Definitions volume of POSIX.1‐2008, with the following

 1. A <space> in the format string, in any context other
    than a flag of a conversion specification, shall be
    treated as an ordinary character that is copied to the

 2. A character in the format string shall be treated as a
    character, not as a <space>.

 3. In addition to the escape sequences shown in the Base
    Definitions volume of POSIX.1‐2008, (where is a one,
    two, or three‐digit octal number, shall be written as a
    byte with the numeric value specified by the octal

 4. The implementation shall not precede or follow output
    from the or conversion specifiers with <blank>
    characters not specified by the operand.

 5. The implementation shall not precede output from the
    conversion specifier with zeros not specified by the

 6. The and conversion specifiers need not be supported.

 7. An additional conversion specifier character, shall be
    supported as follows. The argument shall be taken to be
    a string that may contain <backslash>‐escape sequences.
    The following <backslash>‐escape sequences shall be


    ‐‐  The escape sequences listed in the Base Definitions
        volume of POSIX.1‐2008, (which shall be converted to
        the characters they represent

    ‐‐  where is a zero, one, two, or three‐digit octal
        number that shall be converted to a byte with the
        numeric value specified by the octal number

    ‐‐  which shall not be written and shall cause to ignore
        any remaining characters in the string operand
        containing it, any remaining string operands, and
        any additional characters in the operand The
        interpretation of a <backslash> followed by any
        other sequence of characters is unspecified.  Bytes
        from the converted string shall be written until the
        end of the string or the number of bytes indicated
        by the precision specification is reached. If the
        precision is omitted, it shall be taken to be
        infinite, so all bytes up to the end of the
        converted string shall be written.

 8. For each conversion specification that consumes an
    argument, the next argument operand shall be evaluated
    and converted to the appropriate type for the conversion
    as specified below.

 9. The operand shall be reused as often as necessary to
    satisfy the argument operands. Any extra or conversion
    specifiers shall be evaluated as if a null string
    argument were supplied; other extra conversion
    specifications shall be evaluated as if a zero argument
    were supplied. If the operand contains no conversion
    specifications and operands are present, the results are

10. If a character sequence in the operand begins with a
    character, but does not form a valid conversion
    specification, the behavior is unspecified.

11. The argument to the conversion specifier can be a string
    containing zero or more bytes. If it contains one or
    more bytes, the first byte shall be written and any
    additional bytes shall be ignored. If the argument is an
    empty string, it is unspecified whether nothing is
    written or a null byte is written.  The operands shall
    be treated as strings if the corresponding conversion
    specifier is or and shall be evaluated as if by the
    strtod() function if the corresponding conversion
    specifier is or Otherwise, they shall be evaluated as
    unsuffixed C integer constants, as described by the
    ISO C standard, with the following extensions:

 *  A leading <plus‐sign> or minus‐sign shall be allowed.


 *  If the leading character is a single‐quote or double‐
    quote, the value shall be the numeric value in the
    underlying codeset of the character following the
    single‐quote or double‐quote.

 *  Suffixed integer constants may be allowed.  If an
    argument operand cannot be completely converted into an
    internal value appropriate to the corresponding
    conversion specification, a diagnostic message shall be
    written to standard error and the utility shall not exit
    with a zero exit status, but shall continue processing
    any remaining operands and shall write the value
    accumulated at the time the error was detected to
    standard output.  It is not considered an error if an
    argument operand is not completely used for a or

The following exit values shall be returned:

 0    Successful completion.

>0    An error occurred.


The floating‐point formatting conversion specifications of
printf() are not required because all arithmetic in the
shell is integer arithmetic. The utility performs floating‐
point calculations and provides its own function. The
utility can perform arbitrary‐precision floating‐point
arithmetic, but does not provide extensive formatting
capabilities. (This utility cannot really be used to format
output; it does not support arbitrary precision.)
Implementations are encouraged to support the floating‐point
conversions as an extension.  Note that this utility, like
the printf() function defined in the System Interfaces
volume of POSIX.1‐2008 on which it is based, makes no
special provision for dealing with multi‐byte characters
when using the conversion specification or when a precision
is specified in a or conversion specification. Applications
should be extremely cautious using either of these features
when there are multi‐byte characters in the character set.
No provision is made in this volume of POSIX.1‐2008 which
allows field widths and precisions to be specified as since
the can be replaced directly in the operand using shell
variable substitution. Implementations can also provide this
feature as an extension if they so choose.  Hexadecimal
character constants as defined in the ISO C standard are not
recognized in the operand because there is no consistent way
to detect the end of the constant. Octal character constants
are limited to, at most, three octal digits, but hexadecimal
character constants are only terminated by a non‐hex‐digit
character. In the ISO C standard, the concatenation operator


can be used to terminate a constant and follow it with a
hexadecimal character to be written. In the shell,
concatenation occurs before the utility has a chance to
parse the end of the hexadecimal constant.  The conversion
specification is not part of the ISO C standard; it has been
added here as a portable way to process <backslash>‐escapes
expanded in string operands as provided by the utility. See
also the APPLICATION USAGE section of for ways to use as a
replacement for all of the traditional versions of the
utility.  If an argument cannot be parsed correctly for the
corresponding conversion specification, the utility is
required to report an error. Thus, overflow and extraneous
characters at the end of an argument being used for a
numeric conversion shall be reported as errors.

To alert the user and then print and read a series of

     printf "\aPlease fill in the following: \nName: "
     read name
     printf "Phone number: "
     read phone
To read out a list of right and wrong answers from a file,
calculate the percentage correctly, and print them out. The
numbers are right‐justified and separated by a single <tab>.
The percentage is written to one decimal place of accuracy:

     while read right wrong ; do
         percent=$(echo "scale=1;($right*100)/($right+$wrong)" | bc)
         printf "%2d right\t%2d wrong\t(%s%%)\n" \
             $right $wrong $percent
     done < database_file
The command:

     printf "%5d%4d\n" 1 21 321 4321 54321

         1  21
     54321   0
Note that the operand is used three times to print all of
the given strings and that a was supplied by to satisfy the
last conversion specification.  The utility is required to
notify the user when conversion errors are detected while
producing numeric output; thus, the following results would
be expected on an implementation with 32‐bit twos‐complement
integers when is specified as the operand:


│            │  Standard   │                                           │
│ Argument   Output    Diagnostic Output             │
│5a          │ 5           │ printf: "5a" not completely converted     │
│9999999999  │ 2147483647  │ printf: "9999999999" arithmetic overflow  │
│−9999999999 │ −2147483648 │ printf: "−9999999999" arithmetic overflow │
│ABC         │ 0           │ printf: "ABC" expected numeric value      │
The diagnostic message format is not specified, but these
examples convey the type of information that should be
reported. Note that the value shown on standard output is
what would be expected as the return value from the strtol()
function as defined in the System Interfaces volume of
POSIX.1‐2008. A similar correspondence exists between and
strtoul() and and (if the implementation supports floating‐
point conversions) and strtod().  In a locale using the
ISO/IEC 646:1991 standard as the underlying codeset, the

     printf "%d\n" 3 +3 −3 \’3 \"+3 "’−3"

3     Numeric value of constant 3

3     Numeric value of constant 3

−3    Numeric value of constant −3

51    Numeric value of the character in the ISO/IEC 646:1991
      standard codeset

43    Numeric value of the character in the ISO/IEC 646:1991
      standard codeset

45    Numeric value of the character in the ISO/IEC 646:1991
      standard codeset Note that in a locale with multi‐byte
      characters, the value of a character is intended to be
      the value of the equivalent of the representation of
      the character as described in the System Interfaces
      volume of POSIX.1‐2008.

The utility was added to provide functionality that has
historically been provided by However, due to irreconcilable
differences in the various versions of extant, the version
has few special features, leaving those to this new utility,
which is based on one in the Ninth Edition system.  The
EXTENDED DESCRIPTION section almost exactly matches the
printf() function in the ISO C standard, although it is
described in terms of the file format notation in the Base
Definitions volume of POSIX.1‐2008, Earlier versions of this
standard specified that arguments for all conversions other
than and were evaluated in the same way (as C constants, but
with stated exceptions). For implementations supporting the


floating‐point conversions it was not clear whether integer
conversions need only accept integer constants and floating‐
point conversions need only accept floating‐point constants,
or whether both types of conversions should accept both
types of constants. Also by not distinguishing between them,
the requirement relating to a leading single‐quote or
double‐quote applied to floating‐point conversions even
though this provided no useful functionality to applications
that was not already available through the integer
conversions. The current standard clarifies the situation by
specifying that the arguments for floating‐point conversions
are evaluated as if by strtod(), and the arguments for
integer conversions are evaluated as C integer constants,
with the special treatment of leading single‐quote and
double‐quote applying only to integer conversions.


The Base Definitions volume of POSIX.1‐2008, The System
Interfaces volume of POSIX.1‐2008,

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 .

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‐
pages/reporting_bugs.html .