Go to the previous, next section.

get and put

The actual transfer is performed with the get and put commands. To get a file from the remote computer to the local system, the command takes the form:

 ftp> get filename
 

where filename is the file on the remote system. Again using ftp.uu.net as an example, the file `newthisweek.Z' can be retrieved with

 ftp> get newthisweek.Z
 200 PORT command successful.
 150 Opening ASCII mode data connection for newthisweek.Z (42390 bytes).
 226 Transfer complete.
 local: newthisweek.Z remote: newthisweek.Z
 42553 bytes received in 6.9 seconds (6 Kbytes/s)
 ftp>
 

The section below on using binary mode instead of ASCII will describe why this particular choice will result in a corrupt and subsequently unusable file.

If, for some reason, you want to save a file under a different name (e.g. your system can only have 14-character filenames, or can only have one dot in the name), you can specify what the local filename should be by providing get with an additional argument

 ftp> get newthisweek.Z uunet-new
 

which will place the contents of the file `newthisweek.Z' in `uunet-new' on the local system.

The transfer works the other way, too. The put command will transfer a file from the local system to the remote system. If the permissions are set up for an FTP session to write to a remote directory, a file can be sent with

 ftp> put filename
 

As with get, put will take a third argument, letting you specify a different name for the file on the remote system.

ASCII vs Binary

In the example above, the file `newthisweek.Z' was transferred, but supposedly not correctly. The reason is this: in a normal ASCII transfer (the default), certain characters are translated between systems, to help make text files more readable. However, when binary files (those containing non-ASCII characters) are transferred, this translation should not take place. One example is a binary program--a few changed characters can render it completely useless.

To avoid this problem, it's possible to be in one of two modes---ASCII or binary. In binary mode, the file isn't translated in any way. What's on the remote system is precisely what's received. The commands to go between the two modes are:

 ftp> ascii
 200 Type set to A.   (Note the A, which signifies ASCII mode.)
 
 ftp> binary
 200 Type set to I.   (Set to Image format, for pure binary transfers.)
 

Note that each command need only be done once to take effect; if the user types binary, all transfers in that session are done in binary mode (that is, unless ascii is typed later).

The transfer of `newthisweek.Z' will work if done as:

 ftp> binary
 200 Type set to I.
 ftp> get newthisweek.Z
 200 PORT command successful.
 150 Opening BINARY mode data connection for newthisweek.Z (42390 bytes).
 226 Transfer complete.
 local: newthisweek.Z remote: newthisweek.Z
 42390 bytes received in 7.2 seconds (5.8 Kbytes/s)
 

Note: The file size (42390) is different from that done in ASCII mode (42553) bytes; and the number 42390 matches the one in the listing of UUNET's top directory. We can be relatively sure that we've received the file without any problems.

mget and mput

The commands mget and mput allow for multiple file transfers using wildcards to get several files, or a whole set of files at once, rather than having to do it manually one by one. For example, to get all files that begin with the letter `f', one would type

 ftp> mget f*
 

Similarly, to put all of the local files that end with .c:

 ftp> mput *.c
 

Rather than reiterate what's been written a hundred times before, consult a local manual for more information on wildcard matching (every DOS manual, for example, has a section on it).

Normally, FTP assumes a user wants to be prompted for every file in a mget or mput operation. You'll often need to get a whole set of files and not have each of them confirmed--you know they're all right. In that case, use the prompt command to turn the queries off.

 ftp> prompt
 Interactive mode off.
 

Likewise, to turn it back on, the prompt command should simply be issued again.

Go to the previous, next section.

Copyright © 1998, Software Engineering Laboratory
National Technical University of Athens