From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 14-APR-1993 17:04:42.92
To:	info-vax@crvax.sri.com
CC:	
Subj:	RMS attributes

When you get UUencoded files from a unix source that are ZIP files
or the like (or even if not...see later) the safest way to handle
them is usually to ensure uudecode treats them as bitstreams. On the
version of UUDECODE I have here, this means

$ uudecode file.uue/format:binary

i.e., ensure the "/format:binary" part is there so the result comes
out as a binary file (fixed-512, no record attributes is the usual way).

If this is to be moved somewhere before using, it's a good idea to give
a command via Joe Meadows' FILE utility like

$ file/attr=noimpliedcc uudecoded_file.type

(you replace "uudecoded_file.type" with the real filename, of course.)

The binary file will unzip just fine; the VMS ZIP image generally
creates fixed-512 files. If you UUdecode to text format, you get
variable record length and have corrupted the binary file; this cannot
be easily (perhaps at all) reversed.

If you get a file Uudecoded in binary format and it turns out to be
really a text file, and if this text came from a unix box, the following
FILE command will fix things:

$file/type=lfstream/attr=impliedcc uudecoded_file.type

Note that a pass through an editor may be needed to remove any
block of nulls that might have gotten pulled in past the end of
the data; if it's a text file, this will be obvious and is
readily handled.

The key to getting files across from unix-land generally is to use
binary transfers (ftp in binary mode, etc.) and fix up the file
attributes if you need to, once you can be REALLY sure the file
should be a text file. Stream files of any type and fixed-512
files both are the same in their data; only the attributes control
the interpretation of that data by RMS. Therefore they can be
changed into one another rather freely, the only concern being
that some transfer mechanisms won't respect a short last record
and some others insist on converting implied attributes into a
<cr><lf> pair or some other end-of-record special stuff that
will corrupt a binary file on transfer, even though the transfer
is "supposedly" transparent. Kermit is like this, owing to its
need to handle so many different machines. Be aware of the file
attributes of what you're working with and when sending data
between machines, turn OFF record attributes and use a binary
transfer method. Bashing a file to fixed-512 format is often
necessary to get this to work, so keep your copy of FILE handy.
Glenn
Everhart@raxco.com