Twin Peaks Usenet Archive
Subject: Re: TP gif files
From: daq@hpfcso.HP.COM (Doug Quarnstrom)
Date: 1991-01-10, 13:29
For those of you who do not have anonymous FTP access, here is a file
telling you how to get files via anonymous FTP through your mail
Basically you send mail to this server, it gets the FTP files and
mails them to you. What a good deal. Now you can get all that great
ftp stuff even if your company restricts your access to the net for
BITFTP -- Princeton BITNET FTP Server
BITFTP provides a mail interface to the FTP portion of the IBM
TCP/IP product ("FAL") running on the Princeton VM system, to allow
BITNET/NetNorth/EARN users to ftp files from sites on the Internet.
To use BITFTP, send mail containing your ftp commands to BITFTP@PUCC
(or to BITFTP@PUCC.Princeton.edu).
The first command to BITFTP must be "FTP", "FTPLIST", "HELP", or
"VMS". If you send BITFTP mail or a message containing only the
command "FTPLIST", it will send you a list of some of the hosts that
allow anonymous ftp. (Note that there is no guarantee that BITFTP
can access all the hosts in that list.) Use "HELP" to request a
current copy of this help file. Use "VMS" to request a collection
of tips provided by BITFTP users on how to handle binary files from
BITFTP on VMS systems.
The recommended syntax for FTP requests is:
FTP hostname NETDATA --or-- FTP hostname UUENCODE
USER username password
Following the hostname on the FTP command, you may specify
"UUENCODE" or "NETDATA" to tell BITFTP the format in which you wish
to receive files.
If the username is "anonymous", no password is required; BITFTP will
use your userid and nodeid as the password. Note that on many
systems passwords are case-sensitive; that is, the password may be
required to be in lower case or mixed case or upper case. (The same
is true of directory and file names.)
The following is an example of an ftp request:
FTP f.ms.uky.edu NETDATA
GET robotron.arc msdos.robotron
BITFTP implements a subset of the ftp subcommands provided in the
IBM TCP/IP and uses the same syntax. Therefore, you may find it
useful to obtain the "IBM TCP/IP for VM Command Reference Manual",
IBM order number GC09-1204.
The currently supported subcommands are:
ACCT -- to send host-dependent account information.
format: ACCT account-information
ASCII -- to change the file transfer type to ASCII.
BINARY -- to change the file transfer type to image.
CD -- to change the working directory.
format: CD directory
CLOSE -- to disconnect from the foreign host.
DIR -- to get a list of directory entries.
EBCDIC -- to change the file transfer type to EBCDIC
GET -- to get a file from the foreign host.
format: GET foreignfile
If you specify "localfile", it must be in
the forms "filename.filetype" or "filename",
and the filename and filetype may each be no
more than 8 characters long and may not contain
LOCSTAT -- to display local status information.
LS -- to list the files in a directory.
PWD -- to print the working directory.
QUIT -- to disconnect from the foreign host.
STATUS -- to retrieve status information from a foreign host.
SYSTEM -- to get the name of the foreign host's operating
TYPE -- to specify Image, ASCII, or EBCDIC file transfer.
BITFTP does not provide a PUT capability, and there is no intention
to make it do so in the future.
BITFTP currently accepts requests only via RFC822-format mail, IBM
NOTE-format mail, PROFS-format messages, or files with no headers at
all. BITFTP currently returns the requested files as NETDATA-format
files or as mail files containing UUENCODED data. If you specify
"UUENCODE" or "NETDATA" on your "FTP" command, BITFTP will attempt
to use that format. If you do not specify the format, BITFTP will
attempt to select the appropriate format for your node.
UUENCODED files are broken up into mail files that contain no more
than 50,000 bytes of data. NETDATA-format files that are larger
than 300,000 bytes are sent in 300,000-byte pieces using the BITSEND
function. You should be able to receive such files using the BITRCV
function available from your nearest NETSERV. (If you do not know
how to use NETSERV, ask your local BITNET/EARN/NetNorth Coordinator
for assistance.) If BITRCV is not available for your system, use
the command you normally use to receive NETDATA-format files and
then concatenate the files in the order shown in the BITRCV control
file to recover the original file.
Users in the UK should note that BITFTP attempts to send
NETDATA-format files through the gateway from EARN into Janet via
the NIFTP facility at Rutherford Lab. Note that receiving files via
NIFTP requires an overt action on your part. If you are at a Janet
node and don't know how to use NIFTP, you should ask for assistance
locally. Alternatively, you can ask BITFTP to send your files
UUENCODED inside mail by specifying the "UUENCODE" option.
If BITFTP sends you a file you cannot read, THE FIRST THING TO DO is
to make sure that you specified ASCII if the file should contain
textual material or that you specified BINARY if the file should
contain binary data, executable programs, tar files, or the like.
VMS users should specify BINARY F 512 and should use RECEIVE/BINARY
to receive the NETDATA-format binary files BITFTP sends them.
If BITFTP sends you a uuencoded file that you cannot uudecode, the
first thing to do is to translate all occurrences of 0x7E in the
file to 0x5E and then try uudecoding again. (Some gateways are
changing 5Es to 7Es when the files pass through them.)
There are many different flavors of UUENCODE/UUDECODE. The version
that BITFTP uses puts a "guard character" at the end of each encoded
line. Most implementations of uudecode know to ignore this
character. If yours does not, then you should remove the last
character of each line before attempting to uudecode the file. Note
that the guard character is not always "M"; the short lines at the
end of the file may have some other guard character, rather than
"M". Whatever that character is, it should be removed (or your
uudecode should be fixed).
When BITFTP is told to transfer a file in FIXED format, such as
"BINARY FIXED 128", it will create a file whose total byte count is
an integral multiple of the record length (128, in this case). This
means that the last record may be padded to get it to the specified
record length. In such a case, you may need to use an editor to
shorten the last record so that the total byte count in the file is
correct. (If the file is uuencoded when you receive it, shorten it
AFTER you have uudecoded it.)
In addition to any files you request, you will also receive a mail
file containing a log of your ftp session. In that mail file,
entries prefixed by ">" are your original commands; those prefixed
by ">>" are your commands as interpreted by BITFTP and passed to
TCPIP; those prefixed by ">>>" are your commands as interpreted by
TCPIP and passed to the remote host; those prefixed by "<<<" are
messages from the remote host; and those prefixed by ">>>>" are
completion messages from BITFTP.
If BITFTP is unable to connect to the host you specify, it will send
you mail after the first attempt, but will keep trying at intervals
over three days. The only additional mail file you will receive
will be when the connection is made successfully or when BITFTP
gives up after three days.
The load on BITFTP is often very heavy, and network backlogs are
often so great that it may take several days for a file to get to
you once BITFTP sends it, so please be patient and don't send
multiple requests for the same file. If your system allows you to
send interactive messages, you can inquire about BITFTP's backlog by
sending the query "How are you?", e.g., on a VM system:
TELL BITFTP AT PUCC How are you?
Questions about BITFTP and suggestions for improvements should be
directed to Melinda Varian, MAINT@PUCC on BITNET or
firstname.lastname@example.org on the Internet.
The author gratefully acknowledges the use of the FTP SUBCOM
interface written by David Nessl, the SENDJANI EXEC written by Alan
Flavell, the uuencoding utility written by John Fisher, and the
RFC822 parsing routine written by Eric Thomas. NOTE: If you have
any complaints or suggestions about the way any of these routines
work in BITFTP, please send them to MAINT@PUCC (Melinda Varian), not
to the authors.