GNU bug report logs - #34345
dd: report elapsed time as HH:MM:SS.NNNNNNN

Previous Next

Package: coreutils;

Reported by: L A Walsh <coreutils <at> tlinx.org>

Date: Wed, 6 Feb 2019 11:51:02 UTC

Severity: wishlist

To reply to this bug, email your comments to 34345 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#34345; Package coreutils. (Wed, 06 Feb 2019 11:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to L A Walsh <coreutils <at> tlinx.org>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Wed, 06 Feb 2019 11:51:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Ricky Tigg <ricky.tigg <at> gmail.com>, Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: coreutils v.8.30 – Two fractional digits accuracy. Appropriate notation regarding time elapsed.
Date: Wed, 06 Feb 2019 03:49:46 -0800
On 2/6/2019 1:36 AM, Ricky Tigg wrote:
> Enhancements request
> Hi. Command executed:
>
>
>    - Could values reported at '(8.0 GB, 7.5 GiB)' be displayed using a two
>    fractional digits accuracy (model 1.23 GiB).
>   
----
    Nahhhhh....

Implies more accuracy than there is.

    Use 2-3 digits for reporting.  That way it can be displayed as
2-3 digits, if choice.  If value is between 2 endpoings, choose the
one that keeps the most bits, like 23.5->23, 34.5->35, basically round
to odd.

> entical values may be
> interpreted as a programming issue. Regards.
>   




Information forwarded to bug-coreutils <at> gnu.org:
bug#34345; Package coreutils. (Fri, 08 Feb 2019 21:11:02 GMT) Full text and rfc822 format available.

Message #8 received at 34345 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: L A Walsh <coreutils <at> tlinx.org>, ricky.tigg <at> gmail.com,
 34345 <at> debbugs.gnu.org
Subject: Re: bug#34345: coreutils v.8.30 – Two fractional digits accuracy. Appropriate notation regarding time elapsed.
Date: Fri, 8 Feb 2019 14:10:17 -0700
severity 34345 wishlist
retitle 34345 dd: report elapsed time as HH:MM:SS.NNNNNNN
stop

Hello,

Ricky Tigg's original message was sent to coreutils <at> gnu.org
(not to bug-coreutils <at> gnu.org), and did not create a new bug report:

   https://lists.gnu.org/r/coreutils/2019-02/msg00003.html

This is of course absolutely fine - but PLEASE keep the same mailing 
list when replying (e.g. don't reply to bug-coreutils <at> gnu.org if
the message was sent to coreutils <at> gnu.org).

The original message said:

On 2019-02-06 2:36 a.m., Ricky Tigg wrote:
> Enhancements request
> Hi. Command executed:
>
> # dd if=/dev/zero of=/dev/sdc status=progress
> 8003555840 bytes (8.0 GB, 7.5 GiB) copied, 1994 s, 4.0 MB/s
> dd: writing to '/dev/sdc': No space left on device
> 15638481+0 records in
> 15638480+0 records out
> 8006901760 bytes (8.0 GB, 7.5 GiB) copied, 2014.25 s, 4.0 MB/s
>
>
>     - Could values reported at '(8.0 GB, 7.5 GiB)' be displayed using 
a two
>     fractional digits accuracy (model 1.23 GiB).

That is not likely to change.
The printing code uses a common function (human_readable) that is used
in several other coreutils programs, and the convention is to print up
to 3 digits (or 2 digits with one decimal point).
Examples:
   1.1 KB
    11 KB
   111 KB
    11 MB
   111 MB
   1.1 GB
    11 GB
   111 GB
   1.1 TB

The exact number of bytes is printed at the beginning of the line,
and you can use 'numfmt' to format it to your liking:

    $ dd if=/dev/zero of=/dev/zero bs=1M count=10 2>&1 \
          | tail -n1 | numfmt --to=si --format '%2.5f'
    10.48576M bytes (10 MB, 10 MiB) copied, 0.00315612 s, 3.3 GB/s


>     - Could values reported at '1994 s', '2014.25 s' to be displayed
>     according to notation <*hour*>*h*<*minutes*>*'*<*seconds*>*''*.

An interesting idea.
I couldn't find previous discussion about it, so I'll mark this item
as a "wishlist".

As always, patches are welcomed.

> Potential issue:
> Since values '1994 s', '2014.25 s' expressed here may in the present
> context cover nothing but a same object, non-identical values may be
> interpreted as a programming issue. Regards.

I don't understand the above - can you clarify ?

regards,
 - assaf





Severity set to 'wishlist' from 'normal' Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Fri, 08 Feb 2019 21:11:02 GMT) Full text and rfc822 format available.

Changed bug title to 'dd: report elapsed time as HH:MM:SS.NNNNNNN' from 'coreutils v.8.30 – Two fractional digits accuracy. Appropriate notation regarding time elapsed.' Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Fri, 08 Feb 2019 21:11:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#34345; Package coreutils. (Sat, 09 Feb 2019 20:19:02 GMT) Full text and rfc822 format available.

Message #15 received at 34345 <at> debbugs.gnu.org (full text, mbox):

From: Ricky Tigg <ricky.tigg <at> gmail.com>
To: 34345 <at> debbugs.gnu.org
Date: Sat, 9 Feb 2019 21:18:03 +0100
[Message part 1 (text/plain, inline)]
Covered object by values '1994 s', '2014.25 s' seems to be a unique
time elapsed. Those values can therefore be expected to be identical,
either '1994 s' or '2014.25 s' – 2014 s and 25 hundredths of s –.
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#34345; Package coreutils. (Sat, 09 Feb 2019 20:34:01 GMT) Full text and rfc822 format available.

Message #18 received at 34345 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Ricky Tigg <ricky.tigg <at> gmail.com>, 34345 <at> debbugs.gnu.org
Subject: Re: bug#34345:
Date: Sat, 9 Feb 2019 13:33:43 -0700
On 2019-02-09 1:18 p.m., Ricky Tigg wrote:
> Covered object by values '1994 s', '2014.25 s' seems to be a unique
> time elapsed. Those values can therefore be expected to be identical,
> either '1994 s' or '2014.25 s' – 2014 s and 25 hundredths of s –.
> 

The command was:

> # dd if=/dev/zero of=/dev/sdc status=progress > 8003555840 bytes (8.0 GB, 7.5 GiB) copied, 1994 s, 4.0 MB/s> dd: 
writing to '/dev/sdc': No space left on device> 15638481+0 records in> 
15638480+0 records out> 8006901760 bytes (8.0 GB, 7.5 GiB) copied, 
2014.25 s, 4.0 MB/s
The first status report (with 1994s) is printed due to "status=progress"
and is updated periodically.
The last status line (with 2014.25s) was printed about 20 seconds later,
hence the time difference.






This bug report was last modified 5 years and 82 days ago.

Previous Next


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