bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: printf octal literals


From: Eric Blake
Subject: Re: printf octal literals
Date: Mon, 05 May 2014 09:37:27 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 05/05/2014 05:09 AM, Dan Douglas wrote:
> Just a heads up on something I hadn't noticed: Bash (and dash) treat
> octal literals in printf precision inconsistently (using glibc -- not
> sure if it's a bug or GNUism on that end or the shell):

Umm, there's no such thing as an octal precision printf format.

> 
>     $ bash -c 'printf "<%.010d> <%.*d>\n" 1 010 1'

POSIX is clear that %.010d is identical to %.10d; an embedded precision
is always treated as decimal.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html

precision
    Gives the minimum number of digits to appear for the d, o, i, u, x,
or X conversion specifiers (the field is padded with leading zeros), the
number of digits to appear after the radix character for the e and f
conversion specifiers, the maximum number of significant digits for the
g conversion specifier; or the maximum number of bytes to be written
from a string in the s conversion specifier. The precision shall take
the form of a <period> ( '.' ) followed by a decimal digit string; a
null digit string is treated as zero.

Meanwhile, POSIX says that %.*d is not required for the printf(1)
utility; so this is a bash extension.  The fact that bash is treating
"'%.*d' 010" as an octal 010 rather than a decimal is odd, but I see
nothing that requires it to behave otherwise.

>     <0000000001> <00000001>
> 
> Zsh is also inconsistent, but in the reverse direction:
> 
>     $ zsh -c 'printf "<%.010d> <%.*d>\n" 1 010 1'
>     <00000001> <0000000001>

zsh is buggy. Report it to the zsh folks.

> 
> ksh93 of course follows its usual pattern of ignoring octal literals
> entirely:
> 
>     $ ksh -c 'printf "<%.010d> <%.*d>\n" 1 010 1'
>     <0000000001> <0000000001>

I actually think the ksh behavior makes more sense; and bash could
change to be made compatible with ksh without violating any POSIX
constraints.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]