Re: Progress bar again

[Jim Meyering]

Miika Pekkarinen <address@hidden> wrote:
> has anyone considered the progress bar patch for cp and mv that I sent
> about one month ago? I think it could be very useful while copying large
> files (especially copying large files over NFS). I can make it better
> if/when needed. I could also write something similar progress bar to
> other utilities such dd. Please answer something.

Thank you for all that work.
I have mixed feelings about progress bars.
I do like the progress bars in rsync, but am reluctant to embed
such functionality in fundamental programs like cp and mv.
I'd like to avoid adding any unnecessary complexity.

When having a progress bar is important, can you use rsync?

BTW, did you know that dd already provides a mechanism
for determining its progress?  Here's part of dd's --help output:

    Note that sending a SIGUSR1 signal to a running `dd' process makes it
    print to standard error the number of records read and written so far,
    then to resume copying.

      $ dd if=/dev/zero of=/dev/null& pid=$!
      $ kill -USR1 $pid; sleep 1; kill $pid
      10899206+0 records in
      10899206+0 records out


If there is good case for it, one possibility would be to do
something similar for cp and mv.

By the way, your patch was made invalid by your mail client.
Please configure your mail client not to `wrap' long lines.

Jim

================================
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.