[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7325: new test failure due to non-portability of printf formats like
From: |
Jim Meyering |
Subject: |
bug#7325: new test failure due to non-portability of printf formats like %05.3s |
Date: |
Fri, 12 Nov 2010 15:12:51 +0100 |
Pádraig Brady wrote:
> On 12/11/10 11:22, Jim Meyering wrote:
>> Pádraig Brady wrote:
>>> On 11/11/10 17:54, Paul Eggert wrote:
>> ...
>>>> It's
>>>> not a big deal, but I still mildly prefer the * notation.
>>
>> Same here.
>>
>> However, here's an argument for using a different method, perhaps
>> with a hard-coded mapping from common FS types to known precision:
>>
>> Running these two commands with different ordering prints
>> different results. When the file with NS%10 == 0 comes first,
>> stat suppresses the trailing 0(s):
>>
>> $ stat -c '%4n %.*Z' 3 9
>> 3 1289555520.29981438
>> 9 1289555520.300814502
>>
>> After the first non-multiple-of-10 nanoseconds value,
>> stat prints all trailing 0's:
>>
>> $ stat -c '%4n %.*Z' 9 3
>> 9 1289555520.300814502
>> 3 1289555520.299814380
>
> That's just a special case of:
> find ... | xargs stat ...
> So it's no worse that differences over multiple runs of stat IMHO
>
> As for the general question of using hard coded resolutions for FS types.
> It might be OK as long as you err'd on the side of too big rather than too
> small.
> Though isn't everything going to tend towards nanoseconds going forward?
>
> This feature is starting to seem a bit like over engineering
> for what it gives us TBH. If it was guaranteed to give us
> an indication of the timestamp resolution, then OK
> but otherwise I don't think it's worth it.
I agree.
I'd like to defer the addition of this feature,
at least until it's more predictable.
Is that ok with you, Paul?
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, (continued)
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Pádraig Brady, 2010/11/11
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Eric Blake, 2010/11/11
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Paul Eggert, 2010/11/11
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Pádraig Brady, 2010/11/11
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Jim Meyering, 2010/11/12
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Pádraig Brady, 2010/11/12
- bug#7325: new test failure due to non-portability of printf formats like %05.3s,
Jim Meyering <=
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Paul Eggert, 2010/11/12
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Jim Meyering, 2010/11/13
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Paul Eggert, 2010/11/13
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Jim Meyering, 2010/11/13
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Jim Meyering, 2010/11/13
- bug#7325: new test failure due to non-portability of printf formats like %05.3s, Paul Eggert, 2010/11/13
bug#7325: new test failure due to non-portability of printf formats like %05.3s, Pádraig Brady, 2010/11/03