Re: printf octal literals

[Dan Douglas]

On Monday, May 05, 2014 09:37:27 AM Eric Blake wrote:
> 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.

It's clear, so long as you don't miss the single mention of it! (I read
that paragraph several times today and still needed it pointed out as
usual)

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

I think it makes sense because they do nothing but cause amusing "August
bugs".

What I meant by "usual" is that ksh, mksh (and zsh, by default) all
ignore C octal syntax in EVERY context that normally accepts them, so it
could very well be correct by mistake. ksh completely relies upon either
the `base#num` syntax (like Bash), or setting the radix on the variable
via `typeset -i[base]`.

ksh93 also has a format extension to produce output to any base (using
an extra "dot"), so it can go in both directions (and sequence
expansions accept format strings):

$ ksh -c 'printf "%04..2d " {0..0xf}; echo; print -r {0..2#1111%-4..16d}'
0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
0    1    2    3    4    5    6    7    8    9    a    b    c    d    e    f

--
Dan Douglas