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 s
> 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 pre
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 print
On 5/5/14, 7: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):
>
> $ bash -c 'printf "<%.010d> <%.*d>\n" 1 010 1'
>
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):
$ bash -c 'printf "<%.010d> <%.*d>\n" 1 010 1'
<01> <0001>
Zsh is also inconsisten
