Subject: bug#7325: new test failure due to non-portability of printf formats like %05.3s

From: Jim Meyering <[email-masked]>
Date: Thu, 04 Nov 2010 08:32:32 +0100

Pádraig Brady wrote:

> On 03/11/10 19:27, Eric Blake wrote:
>> On 11/03/2010 12:59 PM, Jim Meyering wrote:
>>> Note that coreutils' printf does not accept the '0' modifier in a %s format.
>>>
>>>     $ env printf '%05.3s\n' 23
>>>     printf: %05.3s: invalid conversion specification
>>>
>>> That's because POSIX says the "0" modifier applies only to the
>>> d, i, o, u, x, X, a, A, e, E, f, F, g, and G conversion specifiers.
>>>
>>> One solution is to trim off the "0".
>>> It's probably a good idea regardless, in case some implementation rejects it.
>>>
>>> On the other hand, I find the zero-padding you currently get
>>> with stat on solaris to be slightly more intuitive.
>>
>> I agree that %05.3:X resulting in 00023 would be ideal.
>
> I disagree because I can't see how that's useful.
> The above is for 023xxxxxx nanoseconds.
> So what is 23 in that context?

The reason I prefer the above is that (regardless of semantics)
it is consistent with what one would expect of a numeric conversion
specifier.  That means no surprises for the user who knows about printf
and no need to document anything different about how stat's %[WXYZ]
specifiers work.