I've seen in many places used install -d
to create directories and install -c
to copy a file. Why not use mkdir
and cp
? Is there an advantage in using install
?
4 Answers
It depends on what you're doing.
The install
command is normally used in installation scripts that come with packages and source code for installing a binary to your system. It can also be used to install any other file or directory. In addition to the -d
and -c
options you have -m
for specifying the new permissions of the file to be installed, so you don't have to do a cp
and a chmod
to get the same result. For instance:
install -m644 "$srcdir/$pkgname-$pkgver-linux64" "$pkgdir/opt/$pkgname"
You also have options -g
and -o
for setting the target group and owner, respectively. This avoids separate calls to chown
. In general, using install
shortens your script and makes it more concise by doing file creation, copying, mode setting and related stuff in one command instead of many.
For reference, see man install
. For usage, just take a look at any installation script shipped with some package source code.
"install" generally combines the following actions:
- Copying of the specified file to the target place, which is being done with respect to processes which use an old copy. Unlike "cp", "install" either unlinks file before the creation of a new one, or (in BSD systems, with -S switch) creates a new one and renames to the target name atomically, which avoids race condition between installing and reopening. If not to use this, copying could fail (with ETXTBSY) for a running binary file, or cause a crash if a library file or a data one is replaced.
- Set proper permissions of the new file without need for separate commands.
- Make intermediate directories, if requested.
- Avoid modifying of a target file if it's identical to the new version (-C switch).
So, it follows Unix approach that a tool shall be made for a single but complete action of installing a file made by a some building tool to its working location.
The complete concept as I've described is implemented in BSD systems (in so-called "xinstall" version); I treat here "safe copy" mode (new version with atomic renaming) as vital for this. Linux systems (from coreutils) miss this important part and are prone to races between deleting and reopening by a bystander process; but this could have been covered by package managers.
-
4The use of
install
or$(INSTALL)
in makefiles also flags those steps as being installation copying steps and not some ordinary copying steps. That could be useful.– KazJul 17, 2017 at 16:01
Apart from the previous descriptions here about the usage, there is a low level difference between cp
and install
, at least on Linux. If copying over an existing file, cp
overwrites the existing inode of the file, while install
always creates a new inode for the same file name.
This makes a difference when installing a new version of a running binary. Using cp
causes an EBUSY error, while install
will succeed. The running binary will still use the old version, but the new version is used if the program is restarted.
-
That's interesting... So it can create a file with the same name but different inode? May 2, 2018 at 12:30
-
3@NeaţuOvidiuGabriel Yes. To the user, there will only be one file, since files are typically looked up by name. But to the file system, there are two files as long as some process holds a reference to the old file. The same can be achieved if you rename or delete a file that is opened by a process, and then create a new file with the same file name. May 3, 2018 at 13:38
If the directory in question already exists:
install -d
will not try to set the ownership and file mode bits.mkdir -p
will try to set the ownership and file mode bits.
This is for install
and mkdir
from GNU coreutils.
They both use the same make_dir_parents
function, but with the preserve_existing
argument set to:
true
forinstall -d
false
formkdir -p
-
3