bug#17505: Pádraig: does this solve your consistency concern? (was bug#17505: dd statistics output)

[Linda Walsh]

Pádraig: you may have missed this as it was a reply to
an old thread, but, changing the subj and composing as new
should prevent that (I hope)....

You were concerned that the user would get different outputs
based on the previously suggested algorithm -- as well as
possibly different output when SIGUSR1 came in.

This idea seems to solve both of those -- so if the patch that was
proposed for this was modified in line with this suggestion,
would there be any further problems?


Linda Walsh wrote:
> Found old bug, still open...
>
> Pádraig Brady wrote:
> > On 07/16/2014 10:38 AM, Pádraig Brady wrote:
> >  
> > > http://bugs.gnu.org/17505#37 was proposed do the following 
> > > automatically (depending on the amount output):
> > >
> > >   268435456 bytes (256 MiB) copied, 0.0248346 s, 10.8 GB/s
> > >
> > > However that wasn't applied due to inconsistency concerns.
> > > I'm still of the opinion that the change above would be a net gain,
> > > as the number in brackets is for human interpretation, and in the vast
> > > majority of cases would be the best representation for that.
> ----
>    One patch that would not be inconsistent:
>
>    If the user uses units of a single system (i.e. doesn't use 'si' 
> and b2 units
> in same statement), then display the summary units using the same 
> notation the
> user used:
>
> dd if=xx bs=256M
> ...(256M copied)....
> vs.
> dd if=xx bs=256MB
> ...(256MB copied)...
>
> > Note another reason to _not_ apply the patch is that
> > requests to print the statistics can come async through SIGUSR1,
> > and thus increase the chances of inconsistent output.
> Solves this too, since the units are decided when the command is parsed,
> so SIGUSR would use the same units as would come out on a final summary.
>
>
> Or is using consistent units w/what the user users not ok?
>
> Note, for statements w/o units (or mixed system), there would be no 
> reason to change
> current behavior.