HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Showing results for 
Search instead for 
Did you mean: 

difference /dev/null

Go to solution
Frequent Advisor

difference /dev/null

Hello All,

Can anyone help me to understand the difference between two commands below?

cp /dev/null /informix/xyx.log
cat /dev/null > informix/xyx.log
Patrick Wallek
Honored Contributor

Re: difference /dev/null

There really isn't any difference in the effect of the commands. Both will null out the /informix/xyx.log file.

If you want to add a 3rd command that also accomplished the exact same thing:

> /informix/xyx.log

Note that the '>' IS part of the command.
James R. Ferguson
Acclaimed Contributor

Re: difference /dev/null


There is no difference.

# cp /dev/null myfile
# cat /dev/null > myfile
# > myfile

...are all variations of creating or truncating 'myfile' to be empty.


Frequent Advisor

Re: difference /dev/null

Thank you so much.
Honored Contributor

Re: difference /dev/null

Both will achieve the same thing in two slightly different ways.

The first one reads /dev/null as if it were a regular file, and places the content to /informix/xyx.log, overwriting what's already there. All the work is done by the /usr/bin/cp command binary.

In the second one, the "cat" command only outputs the contents of /dev/null into the standard output stream, and then the shell redirects that stream to the informix/xyx.log file (because of the ">" redirection operator). Again, the new content overwrites the old. A half of the work is done by /usr/bin/cat, half by the shell.

Neither of these commands are optimal for truncating a file to zero size: running a command that is not built-in to the shell requires a vfork() + exec() system call pair, which causes a new process to be created and eventually torn down. This is not a problem if you need to truncate a small number of files (say, less than a thousand), but the accumulation of extra work gets very noticeable if you're truncating a million files or so.

The optimal way to truncate a file to zero size would usually be:

> /informix/xyx.log

i.e. to redirect the output of [an empty command line] to the file.

This is done completely within the shell process, so the system won't have to spend any time creating and tearing down extra processes.