Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Please note that I don't ask how. I already know options like pv and rsync -P.

I want to ask why doesn't cp implement a progress bar, at least as a flag ?

share|improve this question
How about "The author doesn't feel the need for it"? –  phunehehe Jun 26 '11 at 16:33
For the readers who don't know pv and rsync -P, see move files with progress bar (one of the answers cites a patch to cp so that cp -g gives a progress indicator). –  Gilles Jun 26 '11 at 17:08
A better place to ask would be on the new (since 2010) coreutils user mailing list. –  Faheem Mitha Jun 26 '11 at 21:20

3 Answers 3

up vote 33 down vote accepted

The tradition in unix tools is to display messages only if something goes wrong. I think this is both for design and practical reasons. The design is intended to make it obvious when something goes wrong: you get an error message, and it's not drowned in not-actually-informative messages. The practical reason is that in unix's very early days, there still were teleprinters; that is, the output from programs would be printed on paper, and you don't want to print progress bars.

Whatever the reason, the tradition of only displaying useful messages has stuck in the unix world. Modern tools have sometimes introduced progress bars; in rsync's case, the main motivation is that rsync is often performed over the network, and networks are a lot flakier than local disks, so the progress bar is more useful. The same reasoning applies to wget.

share|improve this answer
This. And cp goes back to the early 1970s: it's bout as traditional as you can get. –  dmckee Jun 27 '11 at 4:54
@dmckee Then why can dd give progress statements? dd goes back to 1966 (OS/360). Unix tools can be verbose if the user wants them to be verbose, but unfortunately you can't say how verbose cp shall be (there is only one additional verbosity level: -v). –  taffer Jan 25 '12 at 19:33
@taffer dd is peculiar in many ways (most obviously, its option syntax) because it's not from unix, it's a clone of an IBM tool. Also, it was mostly used for long tasks on tapes, so its messages told you to come back from your break, unlike cp where in most cases you'd just blink and get your prompt back. –  Gilles Jan 25 '12 at 21:53

This is one of those marginal things where there are arguments for and against adding a progress bar option to cp. The main argument against, is that you may not know ahead of time that you want to know the progress. Ctrl-T/SIGINFO is available on BSD for this purpose, and if that becomes available on GNU/Linux platforms, then there might be more reason for that to trigger progress bar logic in cp. In the meantime a more general solution is to use a separate tool like 'coreutils viewer' to display the status of any process on the system.

share|improve this answer

In the unix world, each tool is designed to do one job and do it well. Why would cp worry about outputting progress when another tool like pv does it already? In the same vein, why do so many programs dump stuff to the screen without any pagination? Because there are already tools for that job such as more (or less). Why do most programs that require editing of files NOT present you an editor and instead outsource to $EDITOR instead? Because that leaves everybody doing the one task they were designed to do, and the user using their favorite editor for all tasks.

Tangentially, most shell programs are designed to have their output piped into other shell programs. The only output they are likely to give is things that would be useful to parse out in the next command in the chain. Programs like cp are used in scripts as well as manually from a terminal, so its output is focused around the exit code and lists of files that failed or succeed.

Always expect to combine tools to accomplish your desired effect.

share|improve this answer
Did pv exist when cp was written? It's a good point, but I have the feeling that in this case, cp was originally deliberately written without progress output, nothing to do with other tools, just the other reasons you and Gilles cite. –  Jefromi Jun 27 '11 at 0:18
@Jefromi: I'm not sure it matters. This isn't a historical question about why cp was one way when it was first coded. The question is why is it that way now. It's been a lot of years and somebody could have added the functionality, but have clearly decided not to. I'm sure the availability of other tools factors into that decision. –  Caleb Jun 27 '11 at 9:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.