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

[Pádraig Brady]

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?

> And I agree that we'd have to trim off the 0 modifier before calling the 
> underlying
> printf %s, and thus be responsible for putting in '0' padding ourselves
> rather than relying on printf() padding.
> 

I'd just strip any leading 0 if a precision is specified,
to suppress the problematic solaris behavior.

cheers,
Pádraig.