cp with progress bar
If you know what you're doing and you'll remember you might like it. But if you're afraid that you'll brake something with that alias just don't use it or create another alias like rsync-cp or whatever suits you (read discussion in comments).
Still this is the single most awesome tip I got some time ago from colleague
If you would like to have copy command with progress just use:
alias cp='rsync -p --progress'Or without --progress and add it when you need it.
Written by Rafał Malinowski
Related protips
10 Responses
Maybe is just me, but I'm not very comfortable in radically overwriting system commands.
As an alternative, Pipe viewer can be used to accomplish this, or use Advanced copy, which is basically standard cp and mv with a patch that will add support for progress bar, by using -g or --progress-bar option.
HINT: If you will use Advanced copy, you may consider putting them in /usr/local/bin under a different name, like cpg and mvg, just to make sure that programs that rely on cp and mv will not break and that ones patched will not be overwritten on next system update.
+1 vimishor
Overriding system commands is not something I'd recommend either.
Guys. Alias is not replacing anything. If you're using cp command in bash scripts it will still use /bin/cp.
I prefer to use pv instead of rsync:
pv file1 > file2.
+1 vimishor. I use cp -Rvf a lot and the -R flag of cp differs from the meaning of rsyncs -R flag. The same things counts for the -f flag. So you have to be aware of that. The equivalent of cp -Rvf in rsync is rsync -rv --force. So in case I alias cp I must use cp -rv --force.
Oh common. I'm making the change and I know that I need to use -r to copy.
If you don't know what you're doing just don't do it. I'm using rsync instead of cp and I don't have problems.
Nobody said anything about replacing a command, but to overwriting a system command, which alias will basically do.
And yes, maybe I will remember by magic two months from now that I have an alias that will break a standard cp command for example, but I also use a lot of scripts that are standard across my team and I can't force anyone to use my crazy aliases.
As a side note, adopting an offensive approach when a bunch of people disagree with you, is not very mature or professional. If you like to play dangerous by overwriting system commands, go ahead and do it, but at least have the decency in respecting other people opinion.
To be exact I respect all opinions and I'm not being disrespectful to anyone !
So I'm going to add this 'disclaimer'. If you know what you're doing and you have more aliases (like I have 91 of them; to servers but not only) and you'll remember you might like it.
If you're afraid that you'll brake something don't use it.
And as I said alias is not overwriting/replacing any cp command used in script. That's because running bash script it's not reading .bashrc and all those files which are read only in interactive mode.
There is great article about it: http://blog.flowblok.id.au/2013-02/shell-startup-scripts.html
Also I'm kinda terminal/bash geek and I love to tinker around ;)
There can be a problem when someone will try to do something on your machine.
The clue here is the understanding what is doing what and when. I'm using it and I'm happy. And for the past year or two I had no problems with that. I'm not arguing that this is the best option for everybody. It's just a tip. Do what you like/want.
To be exact I've tested it.
cp -r -6 tests tests2 with my alias should produce something like this:
```
→ cp -6 tests/ tests2
skipping directory tests/.
sent 21 bytes received 20 bytes 82.00 bytes/sec
total size is 0 speedup is 0.00
```
But used in test.sh it's failing with:
cp: illegal option -- 6
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file target_file
cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file ... target_directory
You finally get the main point: Not everyone has the same workflow as you.
For example, I use aliases to short crazy long commands that I use often and sometimes I need those aliases in my scripts also. Besides that, some scripts that are used across my team can be configured via env vars to do different things according to that developer preferences. So i need to force some scripts to use my dotfiles, because this is my usual workflow.
Maybe for the next guy my workflow is crazy, but I will never insist in convince him that my way is the right way. This is where will come respect other people opinions thing that I talked earlier :-)
You're right for me yours workflow in my opinion is crazy. Especially that "so i need to force some scripts to use my dotfiles" thing :)
We are also using env but it has to be generic as hell to work everywhere cause we are using those scripts to initialize stuff for devs (vagrant though makes life easier with windows users) and for production/staging or even for jenkins.
