bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch to implement progress in dd


From: Bob Proulx
Subject: Re: Patch to implement progress in dd
Date: Tue, 29 Apr 2003 23:37:18 -0600
User-agent: Mutt/1.3.28i

Hi Sean!

Sean Reifschneider wrote:
> This patch implements a "progress=1" option to dd that will display the
> number of blocks written via stderr.  It's just sometimes nice to know
> where in the copy/dump you are.

Thanks for submitting the patch for that functionality to the list.
It is an interesting item.  Please allow me to comment upon it.  I
don't think "progress=1" is of the right spirit for setting that type
of option.  The 1 and 0 don't seem right here.

I personally would rather see something along the lines of the 'wget
--progress=type' option if this feature would be implemented.  That
has more long term expandability and capability.  Check out wget's
option setting and you will see what I mean.  I know wget has been
changing so I will say that I am looking at 1.8.1 right now.

> --- fileutils-4.1-newdd/man/dd.1.old  2003-04-29 22:05:39.000000000 -0600
> +++ fileutils-4.1-newdd/man/dd.1      2003-04-29 22:10:50.000000000 -0600
> @@ -34,6 +34,11 @@
>  of=FILE
>  write to FILE instead of stdout
>  .TP
> +progress=(0|1)
> +display a count of blocks written every second as the program is running.
> +If set to 1, two values are displayed: "X/Y", where the first value is the
> +number of fully written blocks and the second is partially written blocks.
> +.TP
>  seek=BLOCKS
>  skip BLOCKS obs-sized blocks at start of output
>  .TP

Oops!  You missed the first line of the file.  The man pages get
generated automatically from the --help output.

  .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.29.

Therefore the documentation changes need to go into the coreutils.texi
file.

Jim has previously posted the following guidelines which I will
reproduce here.  Perhaps I can beat him to the post.  :-)

Bob

Jim Meyering wrote:
---------
Here are some guidelines for contributing code to the coreutils
package (previously known as the fileutils, textutils, and sh-utils).

Send patches. (send unified diffs, please -- i.e. diff -u format) If your
changes fix bugs, the bar is quite low in that I don't need much more
than to understand what the original problem was.  However, it helps
a lot if you can give me enough information to reproduce the problem.

On the other hand, if you're adding new features, please follow the
guidelines below:

  - convince me that this is a useful change/addition
      (if you're adding yet another option to ls, the above is pretty hard)

  - convince other people of the same thing
      One way to do that is to send mail to address@hidden
      (aka the gnu.utils.bug news group) including as much description
      and justification as you can.  Based on the feedback that generates,
      you may be able to convince me.

Once we agree the change is useful and get around to considering the
actual addition to the code, it helps if you do the following:

  - base your changes on the latest test release -- currently here:
      ftp://alpha.gnu.org/gnu/coreutils/

  - follow the guidelines in the GNU Coding Standards (standards.info)
      which is distributed as part of the autoconf package.

  - include changes to the texinfo documentation, and be sure to update
      the --help output.

  - finally, if the change is `significant' you'll have to send signed
      copyright assignment papers to the FSF

And you'll have to be patient and expect delays on my part.
It is unusual that I spend more than a few hours per week
on the packages I maintain.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]