|HP-UX Reference > R
HP-UX 11i Version 3: February 2007
rcp — remote file copy
Copy One or More Directory Subtrees
rcp [-p] [-S size] [-R size] -r source_dir1 [source_dir2]... dest_dir
Copy Files and Directory Subtrees
rcp [-p] [-S size] [-R size] -r file_or_dir1 [file_or_dir2]... dest_dir
Copy Multiple Files
rcp [-k realm] [-P] [-p] [-S size] [-R size] source_file1 [source_file2]... dest_dir
Copy One or More Directory Subtrees
rcp [-k realm] [-P] [-p] [-S size] [-R size] -r source_dir1 [source_dir2]... dest_dir
The rcp command copies files, directory subtrees, or a combination of files and directory subtrees from one or more systems to another. In many respects, it is similar to the cp command (see cp(1)).
To use rcp, you must have read access to files being copied, and read and search (execute) permission on all directories in the directory path. Note that there are special requirements for third-party transfers, which are described in the Third-Party Transfers section below.
In a Kerberos V5 Network Authentication environment, rcp uses the Kerberos V5 protocol while initiating the connection to a remote host. The authorization mechanism is dependent on the command line options used to invoke remshd on the remote host (i.e., -K, -R, -r, or -k). Kerberos authentication and authorization rules are described in the Secure Internet Services man page, sis(5).
Although Kerberos authentication and authorizations may apply, the Kerberos mechanism is not applied when copying files. The files are still transferred in clear text over the network.
The fallback option can be set in the krb5.conf file within appdefaults Section. Refer to the krb5.conf(4) manpage for more information on the appdefaults Section. If fallback is set to true and the kerberos authentication fails, rcp will use the non-secure mode of authentication.
Options and Arguments
rcp recognizes the following options and arguments:
Constructing File and Directory Names
As indicated above, file and directory names contain one, two, or four component parts:
Each file or directory argument is either a remote file name of the form hostname:path, or a local file name (with a slash (/) before any colon (:)). hostname can be either an official host name or an alias (see hosts(4)). If hostname is of the form ruser@rhost, ruser is used on the remote host instead of the current user name. An unspecified path (that is, hostname:) refers to the remote user's login directory. If path does not begin with /, it is interpreted relative to the remote user's login directory on hostname. Shell metacharacters in remote paths can be quoted with backslash (\), single quotes (''), or double quotes ("" ), so that they will be interpreted remotely.
rcp does not prompt for passwords. In a non-secure or traditional environment, user authorization is checked by determining if the current local user name or any user name specified via ruser exists on rhost. In a Kerberos V5 Network Authentication or secure environment, the authorization method is dependent upon the command line options for remshd (see remshd(1M) for details). In either case, remote command execution via remsh(1) and rcmd(3N), or rcmd_af(3N) in case of IPv6 systems, must be allowed and remshd(1M) must be executable on the remote host.
Third-party transfers in the following form:
rcp ruser1@rhost1:path1 ruser2@rhost2:path2
are performed as:
remsh rhost1 -l ruser1 rcp path1 ruser2@rhost2:path2
Therefore, for a such a transfer to succeed, ruser2 on rhost2 must allow access by ruser1 from rhost1 (see hosts.equiv(4)).
rcp With IPv6 Address
To invoke rcp with an IPv6 address, the IPv6 address must be enclosed in a pair of square brackets ([ and ]) as shown in the example below.
rcp source user@[IPv6_address]:dest
If the IPv6 address is not enclosed within square brackets, the first occurrence of a colon (:) is treated as the separator between the hostname and the path.
The rcp routine is confused by any output generated by commands in a .cshrc file on the remote host (see csh(1)).
Copying a file onto itself, for example:
rcp path `hostname`:path
may produce inconsistent results. The current HP-UX version of rcp simply copies the file over itself. However, some implementations of rcp, including some earlier HP-UX implementations, corrupt the file. In addition, the same file may be referred to in multiple ways, for example, via hard links, symbolic links, or NFS. It is not guaranteed that rcp will correctly copy a file over itself in all cases.
Implementations of rcp based on the 4.2BSD version (including the implementations of rcp prior to HP-UX 7.0) require that remote users be specified as rhost.ruser. If the first remote host specified in a third party transfer (rhost1 in the example below) uses this older syntax, the command must have the form:
rcp ruser1@rhost1:path1 rhost2.ruser2:path2
since the target is interpreted by rhost1. A common problem is encountered when two remote files are to be copied to a remote target that specifies a remote user. If the two remote source systems, rhost1 and rhost2, each expect a different form for the remote target, the command:
rcp rhost1:path1 rhost2:path2 rhost3.ruser3:path3
will certainly fail on one of the source systems. Perform such a transfer using two separate commands.
With the existing implementation of rcp, the remote copy may result in a system overwrite as described in the following example.
rcp -r path root@hostname: /
In this example, if you run rcp as root, and unintentionally type a space between the colon (:) and the slash (/), then rcp assumes both path and root@hostname: (the remote machine's root directory) as source. rcp always interprets the last argument as the destination. Therefore, the destination directory is the local machine's root directory (/). rcp copies the content of path to the root directory (/) first. It then does another copy with root@hostname as source to the root directory (/) again. This second copy overwrites the local system's root directory (/) with the remote system's root directory (/).
Diagnostics can occur from both the local and remote hosts. Those diagnostics that occur on the local host before the connection is completely established are written to standard error. Once the connection is established, any error messages from the remote host are written to standard output, like any other data.