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
signature.asc
Description: OpenPGP digital signature
