![]() | ![]() |
Each of the two names, or path specifications, on the command line represents files or directories in the following manner (it is fairly consistent with the behavior of Unix cp or rcp):scp name-of-source name-of-destination
[106]We say "must," but technically you may specify a file as a destination in some cases. However, this behavior is probably not what you want. As your multiple files get copied into a single destination file, each is overwritten by the next.
Table 7-3 summarizes the syntax of an scp path.$ scp myfile myfile2 A local copy just like cp $ scp myfile bob@host1: Copy . /myfile to ~bob on host1 $ scp bob@host1:myfile . Copy ~bob/myfile on host1 to ./myfile $ scp host1:file1 host2:file2 Copy file1 from host1 to file2 on host2 $ scp bob@host1:file1 jen@host2:file2 Same as above, but copying from bob's to jen's account
Field | Other Syntax | Optional? | Default for Local Host | Default for Remote Host |
---|---|---|---|---|
Username | Followed by @ | Yes | Invoking user's username | Invoking user's username |
Hostname | Followed by : | Only if username is omitted and path is present | None, file is accessed locally | N/A |
Port number [107] | Preceded by # | Yes | 22 | 22 |
Directory path | N/A | Only if hostname is present | Current (invoking) directory | Username's remote home directory |
Watch out for wildcards in remote file specifications, as they are evaluated on the local machine, not the remote. For example, this attempt is likely to fail:$ scp *.txt server.example.com:
The Unix shell attempts to expand the wildcard before scp1 is invoked, but the current directory contains no filename matching "server.example.com:*.txt". C shell and its derivatives will report "no match" and not execute scp1. Bourne-style shells, noticing no match in the current directory, will pass the unexpanded wildcard to scp1, and the copy may succeed as planned, but this coincidental behavior shouldn't be relied on. Always escape your wildcards so they are explicitly ignored by the shell and passed to scp1:$ scp1 server.example.com:*.txt . Bad idea!
scp2 does its own regular expression matching after shell-wildcard expansion is complete. The sshregex manpage for SSH2 (see Appendix A, "SSH2 Manpage for sshregex") describes the supported operators. Even so, escape your wildcard characters if you want your local shell to leave them alone.$ scp1 server.example.com:\*.txt .
If you forget the -r option when copying directories, scp complains:# SSH1, SSH2, OpenSSH $ scp -r /usr/local/bin server.example.com:
Although scp can copy directories, it isn't necessarily the best method. If your directory contains hard links or soft links, they won't be duplicated. Links are copied as plain files (the link targets), and worse, circular directory links cause scp1 to loop indefinitely. (scp2 detects symbolic links and copies their targets instead.) Other types of special files, such as named pipes, also aren't copied correctly.[108] A better solution is to use tar, which handles special files correctly, and send it to the remote machine to be untarred, via SSH:$ scp /usr/local/bin server.example.com: /usr/local/bin: not a regular file
[108]These limitations also are true when copying single files, but at least you see the erroneous result quickly. With directories, you can copy a hierarchy incorrectly and not notice.
$ tar cf - /usr/local/bin | ssh server.example.com tar xf -
For example, if you transfer your entire home directory to a remote machine, you probably want to keep the file attributes the same as the original:# SSH1, SSH2, OpenSSH $ scp -p myfile server.example.com:
$ scp -rp $HOME server.example.com:myhome/
[109]In some earlier versions of SSH2, this option has no effect.
If you've ever wanted a "secure move" command in addition to secure copy, you can define one in terms of scp2 -u:# SSH2 only $ scp2 myfile server.example.com: $ ls myfile myfile $ scp2 -u myfile server.example.com: $ ls myfile myfile: No such file or directory
$ alias smv='scp2 -u'
Then you connect to server.example.com and find, to your horror, that mydir was a file, not a directory, and you just overwrote it! The -d option prevents this tragedy. If the destination isn't a directory, scp complains and exits without copying the file.# SSH1, SSH2, OpenSSH $ scp2 myfile server.example.com:mydir $ rm myfile
This option is necessary only if you are copying a single file. If you are copying multiple files or a directory, all the scp implementations check by default that the remote destination is a directory.[110]# SSH1, SSH2, OpenSSH $ scp2 -d myfile server.example.com:mydir warning: Destination file is not a directory. warning: Exiting.
[110]There's one degenerate case. If your copy occurs on a single machine, e.g., scp *.c mydir, the scp client doesn't necessarily check that mydir is a directory.Another safety feature of scp2 is the -n option, which instructs the program to describe its actions but not perform any copying. This is useful for verifying the behavior of scp2 before executing a potentially risky command.
# SSH2 only $ scp2 -n myfile server.example.com: Not transferring myfile -> server.example.com:./myfile (1k)
[111]For starters, scp1 must be compiled with the configuration flag -- with-scp-stats, or else statistics will be unavailable. [Section 4.1.5.11, "scp behavior"]
For each file, scp1 displays the name, the size, the transfer rate, and a two-part progress meter about the transmission. "ETA" (Estimated Time of Arrival) is the estimated transfer time, and the final number is the percentage of the file transmitted so far. While the file is transferring, the ETA value counts down to zero and the percentage increases to 100, though you can't see this on the printed page. Although the statistics are informative, you might want to change or disable them. For example, you might prefer to turn them off when scp1 is part of a batch job that shouldn't produce screen output. This statistics display can be configured in several ways, using command-line options and environment variables (see Table 7-4: note that command-line options take precedence over environment variables).$ scp1 myfile* server.example.com: myfile1 | 50 KB | 50.0 kB/s | ETA: 00:00:00 | 100% myfile2 | 31 KB | 31.3 kB/s | ETA: 00:00:00 | 100% myfile3 | 3 KB | 3.8 kB/s | ETA: 00:00:00 | 100%
Desired Outcome | Using Options | Setting Environment Variables |
---|---|---|
No output [112] | scp1 -q | SSH_NO_SCP_STATS |
Output, but not file-by-file | scp1 -Q -A | SSH_NO_ALL_SCP_STATS SSH_SCP_STATS |
Output file-by-file | scp1 -Q -a | SSH_ALL_SCP_STATSSSH_SCP_STATS |
[112]Also works for OpenSSH's scp client.
First, you may control the presence or absence of statistics at all. This is done with the options -q and -Q, or the environment variables SSH_SCP_STATS and SSH_NO_SCP_STATS. To disable statistics, use either of the following:To enable statistics, use either of these:# SSH1, OpenSSH $ scp -q myfile server.example.com: # SSH1 only $ setenv SSH_NO_SCP_STATS 1 $ scp1 myfile server.example.com:
If statistics are enabled, you may also choose to print file-by-file statistics. This is done with the options -a and -A, or the environment variables SSH_ALL_SCP_STATS and SSH_NO_ALL_SCP_STATS. To print file-by-file statistics, use either of these:# SSH1 only $ scp1 -Q myfile server.example.com: # SSH1 only $ setenv SSH_SCP_STATS 1 $ scp1 myfile server.example.com:
or to print a single, cumulative statistic:# SSH1 only $ scp1 -Q -a myfile server.example.com: # SSH1 only $ setenv SSH_ALL_SCP_STATS 1 $ scp1 myfile server.example.com:
# SSH1 only $ scp1 -Q -A myfile server.example.com: # SSH1 only $ setenv SSH_NO_ALL_SCP_STATS 1 $ scp1 myfile server.example.com:
The progress indicators (dotted lines) change as the files are transferred, but frankly we find them unintuitive. To suppress the statistics display, use the -Q command-line option (yes, it has the opposite meaning of SSH1's -Q option):$ scp2 myfile* server.example.com: Transfering myfile1 -> server.example.com:./myfile1 (50k) |................................................................| 51200 bytes transferred in 1.00 seconds [50.0 kB/sec]. Transfering myfile2 -> server.example.com:./myfile2 (30k) |................................................................| 31744 bytes transferred in 1.03 seconds [31.3 kB/sec]. Transfering myfile3 -> server.example.com:./myfile3 (3k) |................................................................| 3068 bytes transferred in 0.79 seconds [3.8 kB/sec].
$ scp2 -Q myfile server.example.com:
# SSH1, SSH2 $ scp -S /usr/alternative/bin/ssh myfile server.example.com:
On the other hand, if you copy from the remote to the local machine, you see:$ scp -v myfile server.example.com: Executing: host server.example.com, ..., command scp -v -t . ...
Again, it's likely you'll never use these options, but they're useful to know when reading scp's output in verbose mode. Also, the scp2 manpage mentions them, so it's good to understand what they are.$ scp -v server.example.com:myfile . Executing: host server.example.com, ..., command scp -v -f . ...
![]() | ![]() | ![]() |
7.4. Client Configuration in Depth | ![]() | 7.6. Summary |
Copyright © 2002 O'Reilly & Associates. All rights reserved.