Bug 237553 - cp with progress would be nice
cp with progress would be nice
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
bzcl34nup
: FutureFeature
Depends On:
Blocks: 219546
  Show dependency treegraph
 
Reported: 2007-04-23 15:08 EDT by Jeremy Katz
Modified: 2013-09-02 06:58 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-08 09:40:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jeremy Katz 2007-04-23 15:08:40 EDT
There are a lot of cases when you're copying something locally that being able
to have a progress indicator like you get with scp or rsync would be nice.  And
rather than writing Yet Another Utility, it seems like the right thing to do is
for cp to provide the functionality.
Comment 1 Jim Meyering 2007-04-23 16:43:19 EDT
Hi Jeremy,
Many people have requested this, over the years, and there are probably a few
complete patch sets implementing it.  Why do you think it's best to add this to
cp, when you can already use rsync as a cp-replacement?
Comment 2 Jeremy Katz 2007-04-23 16:48:52 EDT
(In reply to comment #1)
> Many people have requested this, over the years, and there are probably a few
> complete patch sets implementing it.  Why do you think it's best to add this to
> cp, when you can already use rsync as a cp-replacement?

Because then you have a dependency on rsync instead of cp... cp is pretty much
guaranteed to exist, rsync not as much.  Also, rsync is in /usr/bin whereas cp
is in /bin.  And rsync is 5 times larger.

Given that a lot of the time you're going to care about text mode cp and
progress is in early boot, you want to avoid all of the above.
Comment 3 Jim Meyering 2007-04-23 17:18:49 EDT
Well, consider that some folks want a GUI-oriented progress bar, and some want
text-only.  Some are happy to incur the cost of a curses library, others want
the minimal footprint and are happy with less eye candy.  We've hashed out all
of this, over the years, and came to the conclusion that if there is to be any
such thing associated with GNU cp (and mv, and dd, and maybe others, like
install), then the mechanism must be sufficiently generic to work with an
independent program that would be in charge of displaying the progress meter. 
Then, the core copying code needn't be polluted with code that some will never
want or use.  Here's a proposed implementation from 2004:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/1663
Comment 4 Jeremy Katz 2007-04-23 17:24:12 EDT
(In reply to comment #3)
> Well, consider that some folks want a GUI-oriented progress bar, and some want
> text-only.  Some are happy to incur the cost of a curses library, others want
> the minimal footprint and are happy with less eye candy.  We've hashed out all
> of this, over the years, and came to the conclusion that if there is to be any
> such thing associated with GNU cp (and mv, and dd, and maybe others, like
> install), then the mechanism must be sufficiently generic to work with an
> independent program that would be in charge of displaying the progress meter. 
> Then, the core copying code needn't be polluted with code that some will never
> want or use.  Here's a proposed implementation from 2004:
> http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/1663

And at this point, you have entered well into the realm of over-engineering a
simple problem ;-)

If you're using curses, etc and wanting to show the output of cp, you're already
writing an app at which point the part of cp that are going to be cared about
aren't that hard to implement.  The value here is in being able to have a shell
script give some form of progress feedback as it copies a large file.
Comment 5 Jim Meyering 2007-04-23 18:11:29 EDT
From a distance, most problems look simpler than they are :-)

If you're interested in copying a single file, then maybe dd already provides
what you want?  From dd --help:

Sending a USR1 signal to a running `dd' process makes it
print I/O statistics to standard error and then resume copying.

  $ dd if=/dev/zero of=/dev/null& pid=$!
  $ kill -USR1 $pid; sleep 1; kill $pid
  18335302+0 records in
  18335302+0 records out
  9387674624 bytes (9.4 GB) copied, 34.6279 seconds, 271 MB/s

With that basis, a little wrapper script could do what you want.
Comment 6 Douglas E. Warner 2007-11-08 21:00:45 EST
I agree that a progress bar in cp & mv would be very nice at times.  rsync can 
be very overkill (or unusable in certain situations (like writing to an FS 
that doesn't support dot files - vfat, for example - and I would prefer not to 
use rsync's -T option to write to yet another fs).

This bug exists on other forums as well:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/64067
Comment 7 Bug Zapper 2008-04-03 20:13:47 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 8 Ondrej Vasik 2008-04-25 06:07:58 EDT
Adding words future feature and moving back to ASSIGNED. As Jim said, there are
already some complete patches implementing the progress bar feature to cp, mv
and install - usually via long option or via -g option. So far it seems that
upstream is not interested in accepting progress bar feature (even via long
option) and making fork will mean one more patch which will be not oneliner and
will need some maintainance as cp/mv/install source codes are changing quiet a
lot between releases.
Comment 11 Ondrej Vasik 2010-02-08 09:40:01 EST
Time to close that bugzilla...
Discussed many times on upstream list (see archives),
in bugzillas of other linux distributions (e.g.
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/64067
http://www.linux-archive.org/archlinux-development/167447-add-g-option-cp-mv.html
)

If you really want to have this behaviour, you could use some shell script alias to get this. One of such scripts is available at http://chris-lamb.co.uk/2008/01/24/can-you-get-cp-to-give-a-progress-bar-like-wget/  . Closing WONTFIX.
Comment 12 Steve Tyler 2013-09-01 17:53:25 EDT
As of F19, the cp command has the -v (--verbose) option that shows what files are being copied:

$ man cp
...
       -v, --verbose
              explain what is being done
...

$ tar -xf python-bugzilla-0.9.0.tar.bz2 
$ ls
python-bugzilla-0.9.0/  python-bugzilla-0.9.0.tar.bz2
$ 
$ cp -v -a python-bugzilla-0.9.0 foo-1
‘python-bugzilla-0.9.0’ -> ‘foo-1’
‘python-bugzilla-0.9.0/.mailmap’ -> ‘foo-1/.mailmap’
‘python-bugzilla-0.9.0/bz-api-notes.txt’ -> ‘foo-1/bz-api-notes.txt’
... [snipped] ...
‘python-bugzilla-0.9.0/bin/bugzilla’ -> ‘foo-1/bin/bugzilla’
‘python-bugzilla-0.9.0/bugzilla.1’ -> ‘foo-1/bugzilla.1’
‘python-bugzilla-0.9.0/setup.py’ -> ‘foo-1/setup.py’
$ ls
foo-1/  python-bugzilla-0.9.0/  python-bugzilla-0.9.0.tar.bz2
$ 

Tested with:
$ rpm -qf `which cp`
coreutils-8.21-11.fc19.x86_64
Comment 13 Kamil Dudka 2013-09-02 03:09:31 EDT
(In reply to Steve Tyler from comment #12)
> As of F19, the cp command has the -v (--verbose) option that shows what
> files are being copied:

The --verbose option has been there at least since fileutils-3.8.3b (released in 1993), I did not dig deeper in the history...
Comment 14 Steve Tyler 2013-09-02 06:58:05 EDT
Thanks for your digging, Kamil. None of the earlier comments mentioned the --verbose option, so I assumed that it must have been added more recently than 2010 (Comment 11).

Note You need to log in before you can comment on or make changes to this bug.