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.
cat a > b

and

cp a b

If they are functionally the same for all intents and purposes, which one is faster?

share|improve this question
1  
Why don't you test it? –  user unknown Jun 30 '12 at 18:23
add comment

4 Answers 4

In terms of functionality I think they are the same.

If I had to venture a guess about which is faster, I would say the cp command because its purpose is to do file operations just for copy purposes, so it would be optimized for that.

cat, by contrast, is meant concatenate files, meaning joining several files into a series. If no file is specified, it will display a file to the console (thanks to @bahamat for reminding us). In this example the output is redirected to another file. I think this indirection would be less efficient than a direct cp.

I don't know if the difference would be noticeable for regular sized files, though it would be interesting to time these on very large files. I guess one could do repeated trials with /usr/bin/time and see if one is consistently faster/slower than the other.

Do you have any particular reason to ask about this, or is it just simple curiosity (nothing wrong with that at all of course)

share|improve this answer
    
I'm also wondering if there are some strange cases where cat might modify the contents as it passes it through whereas cp wouldn't. I don't know enough about the details of what goes on here. What drove me to ask the question is I saw in one of my shell scripts two tasks accomplishing the same thing but using these different methods and I started wondering what the difference was between them, and if I had that in mind when I wrote them. –  Steven Lu Jun 30 '12 at 2:38
2  
There is 1 important functional difference between the 2; permissions. cp will try and keep the same file permissions (mode) on the new file as are on the original. Obviously this may not be possible due to filesystem restrictions or other factors though. –  Patrick Jun 30 '12 at 2:39
3  
cat is not to display a file to the screen. cat is short for "concatenate", which is defined as "to unite in a series or chain". The original purpose of cat was to combine multiple files into one (e.g., cat file1 file2). It just so happens that if you combine one file with nothing it prints only that one. –  bahamat Jun 30 '12 at 6:13
2  
@Patrick cp will keep the same permissions only if -p option is used. Otherwise it will create absolutely new file according to umask. Issue about timestamps is the same. –  rush Jun 30 '12 at 8:09
2  
@JamesMcLeod there is no such thing a an EOF that cat responds to when reading from a file. @Steven cat is designed to be perfectly transparent. It doesn't change anything. –  jippie Jun 30 '12 at 8:11
show 10 more comments

Functionally similar, but specifically different. Essentially, they both read a bunch of data from the first file, write it to another file.

When I do an strace on Linux:

$ strace cat /etc/fstab > test.txt
...
open("/etc/fstab", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=691, ...}) = 0
fadvise64_64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
read(3, "# /etc/fstab: static file system"..., 32768) = 691
write(1, "# /etc/fstab: static file system"..., 691) = 691
read(3, "", 32768)                      = 0
close(3)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?

$ strace cp /etc/fstab test.log
...
open("/etc/fstab", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=691, ...}) = 0
open("test.log", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
read(3, "# /etc/fstab: static file system"..., 32768) = 691
write(4, "# /etc/fstab: static file system"..., 691) = 691
read(3, "", 32768)                      = 0
close(4)                                = 0
close(3)                                = 0
_llseek(0, 0, 0xbfaa3fb0, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
share|improve this answer
    
Did you forget the -f in your strace of the cat-command, or where is the open for FD 1? –  Nils Jun 30 '12 at 20:31
    
@Nils there is no open for FD 1, its already open when the program is executed (programs inherit open file descriptors, and FD 1 is already opened by the shell). –  Patrick Jun 30 '12 at 20:56
add comment

There isn't much difference: both copy the content of the old file into a new file with the same content. Both overwrite the target if it is an existing file.

Some old systems might stop copying or truncate lines if you try to copy binary files with cat, because they might choke on null characters. I don't think any unix system you're likely to encounter now has a problem there. cp is guaranteed not to have a problem.

cp allows you to specify a directory as the destination: the file is copied to have the same name as the original, in the new directory.

If the destination doesn't exist, cp uses the permission bits of the source file, modified by the current umask.

You can protect against overwriting the target file when doing cat … >target by setting the noclobber option in the shell with set -C. You can protect against overwriting the target file with cp by passing the -i option (alias cp='cp -i'); cp will ask for confirmation.

It is often useful to preserve the date of the original file. You can use cp -p for that.

Performance will vary, depending on the size of the file, the filesystem, the kind of source and target disk, the operating system, etc. For raw disk copies under Linux, I found next to no difference.

share|improve this answer
add comment

Look like cat is faster than cp

root@SHW:/tmp# time cp debug.log test1
real    0m0.021s
user    0m0.000s
sys 0m0.000s
root@SHW:/tmp# time cat debug.log > test2
real    0m0.013s
user    0m0.000s
sys 0m0.000s
root@SHW:/tmp# du -h debug.log 
4.0K    debug.log
root@SHW:/tmp# file debug.log
debug.log: ASCII text
share|improve this answer
    
Does the time also include the > operation, of only the cat command itself? –  Bernhard Jun 30 '12 at 11:11
    
Yes. It includes > operation. Time takes command as an argument –  SHW Jun 30 '12 at 11:13
    
Your measurement proves nothing. The time is far too small to be measured accurately. –  Gilles Jun 30 '12 at 13:19
    
Yeah. But you can crosscheck against GB files. –  SHW Jun 30 '12 at 15:31
3  
Please repeat your test with a different file using cat first. Then cat is probably slower than cp. I suspect you are seeing a file being read from cache in the second command. –  Nils Jun 30 '12 at 20:34
add comment

Your Answer

 
discard

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.