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