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

Previous Next

Package: coreutils;

Reported by: Jim Meyering <jim <at> meyering.net>

Date: Wed, 3 Nov 2010 18:56:02 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: 7325 <at> debbugs.gnu.org, Paul Eggert <eggert <at> CS.UCLA.EDU>,  Jim Meyering <jim <at> meyering.net>
Subject: bug#7325: new test failure due to non-portability of printf formats like %05.3s
Date: Mon, 08 Nov 2010 12:59:51 +0000
On 06/11/10 14:20, Pádraig Brady wrote:
>  On 06/11/10 02:54, Paul Eggert wrote:
>> On 11/04/2010 11:34 PM, Jim Meyering wrote:
>>> Pádraig Brady wrote:
>>>> I still slightly prefer just using %.X as
>>>> it's backwards compat with older coreutils (excluding 8.6).
>>>
>>> So do I.
>>
>> I built that and tried it out, and found another problem that has been
>> annoying me for years in other programs: 'stat' prints out unnecessary
>> trailing zeros for time stamps, when the file system resolution is
>> coarser than nanosecond resolution.  So I figured I'd fix that too,
>> for 'stat' (other programs can be fixed later).  With this fix, %.X
>> outputs the time stamp but omits trailing zeros if it can infer that
>> the file system would always put zeros there.  If you want a specific
>> number of zeros, you can use something like %.3X or %.9X (or %.100X :-).
> 
> Interesting. So it's variable precision by default
> 
> $ touch -d '1970-01-01 18:43:33.5000000000' 2; ~/git/t/coreutils/src/stat -c "%.W %.X %.Y %.Z" 2
> 0.000000000 63813.500000000 63813.500000000 1289052572.699980883
> $ touch -d '1970-01-01 18:43:33.5000000000' 2; ~/git/t/coreutils/src/stat -c "%.W %.X %.Y %.Z" 2
> 0.00000000 63813.50000000 63813.50000000 1289052573.53698077
> 
> I like it.

One caveat we should at least document is
we can't rely on string comparison of timestamps.
I.E. shell code like this could fail, because
a change in atime for example, could cause
a change in the returned mtime.

# Wait for file to be modified
"$ts" = $(stat -c "%.Y" file)
while [ "$ts" = $(stat -c "%.Y" file) ]; do sleep .1; done

cheers,
Pádraig.

From 42d77a300234f608b71c46f6a39bb3a1f4cb31d3 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <P <at> draigBrady.com>
Date: Mon, 8 Nov 2010 12:49:30 +0000
Subject: [PATCH] doc: mention a caveat with the new sub-second precision stat format

* doc/coreutils.texi (stat invocation): Dissuade the use of
the auto precision format with subsequent string comparisons.
---
 doc/coreutils.texi |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 8dfb069..e310c33 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -10721,7 +10721,9 @@ print after the decimal point. For example, @samp{%.9X} outputs the
 last access time to nanosecond precision.  If a period is given but no
 precision, @command{stat} uses the estimated precision of the file
 system. When discarding excess precision, time stamps are truncated
-toward minus infinity.
+toward minus infinity.  Since this estimated precision can return
+differing numbers of trailing zeros, the result should not be used
+with string comparison operators in shell scripts for example.

 @example
 zero pad:
-- 
1.6.2.5




This bug report was last modified 14 years and 191 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.