83

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 ?

3

3 Answers 3

Reset to default
86

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.

4
  • 6
    This. And cp goes back to the early 1970s: it's bout as traditional as you can get.
    – dmckee --- ex-moderator kitten
    Jun 27, 2011 at 4:54
  • 5
    @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, 2012 at 19:33
  • 10
    @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 'SO- stop being evil'
    Jan 25, 2012 at 21:53
  • @Gilles'SO-stopbeingevil' "it's a clone of an IBM tool" => dd isn't a clone of any IBM tool as such. Its syntax is vaguely reminiscent of IBM OS/360 JCL's DD statement, but that's not a "tool" per se, and far from being a clone, the syntax is totally incompatible at the level of details, despite emulating its style. I guess the closest OS/360 tool to dd would something like IEBGENER, but I've never heard anyone claim dd was inspired by IEBGENER specifically as opposed to the JCL DD statement in general (which you use with every tool, not just IEBGENER)
    – Simon Kissane
    Mar 28 at 0:55
19

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.

3
  • 7
    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.
    – Cascabel
    Jun 27, 2011 at 0:18
  • 2
    @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, 2011 at 9:16
  • I don't agree that the availability of pv is a good argument agains cp providing progress when copying a file for three reasons: (1) pv doesn't know how big the file is, so it can't provide you with progress information, (2) does't work with cp -r, and (3) IMHO providing progress is part of a tool's job, if a user requires progress information. I mean, cp even has a switch to provide a different kind of progress information: -v!
    – Feuermurmel
    Feb 3 at 18:20
6

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 the Coreutils Progress Viewer (progress, formerly know as cv) to display the status of any process on the system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .