Documentation below is converted man page; see end of page for copyright information. Tutorial-style instructions specific to World will be forthcoming
MCVERT(LOCAL) UNIX System V (25Sep92) MCVERT(LOCAL)
NAME
mcvert - BinHex 4.0 to MacBinary file conversion utility
SYNOPSIS
mcvert { [option] ... name ... } ...
DESCRIPTION
The mcvert program translates files between MacBinary format
and other formats often used in exchanging Macintosh files.
See FILE FORMATS below for a description of the file formats
supported.
PARAMETERS
The defaults for the parameters are -xDqv: convert BinHex
4.0 files (x) to MacBinary files (D), bypass automatic
unpacking of PIT files (q), and provide a verbose level of
output (v).
OPTIONS
All the options, other than FORMAT OPTIONS described below,
are listed here. From each set, one and only one
alternative is active for any one file.
U | D
When option 'U' is selected, the conversion that takes
place is the one suitable for Uploading files. That
is, the conversion is from MacBinary to something else
when 'U' is selected. Conversely, option 'D', as in
Download, converts from something to MacBinary.
p | q
If a BinHex to MacBinary conversion is taking place and
option 'p' is selected, any file of type "PIT " will be
unpacked into its constituent parts. This option does
not recursively unpack "PIT " files packed in "PIT "
files. If a MacBinary to BinHex conversion is taking
place, this option is currently ignored.
S | s | V | v | H
Normally, mcvert prints to stderr information about the
files it is creating. Selecting option 'S', as in
Silent, disables all such reporting. Option 's', as in
silent, disables all but the "Converting ..." messages.
Option 'V', for very Verbose, displays debugging
information as well. Option 'v', as in verbose, emits
generally useful information. Option 'H', as in
heuristic, disables the skip-legal-but-suspect-lines
heuristic used when processing BinHex 4.0 formatted
input files. See BUGS below for details on the
heuristic.
I Option 'I', as in Information only, does not write
Page 1 (printed 1/23/96)
MCVERT(LOCAL) UNIX System V (25Sep92) MCVERT(LOCAL)
output files, but does indicate which output files
would normally be written. All other operations are
performed, including verifying file formats and
calculated CRC values. The 'I' option basically
provides a non-destructive verification of the files
and their processing. It is also a soothing balm for
the somewhat paranoid, since it reports what files
would be changed, without actually changing them.
FILE FORMATS
The primary formats in which Macintosh files are represented
on non-Macs are:
MacBinary:
An eight bit wide representation of the data and
resource forks of a Mac file and of relevant Finder
information, MacBinary files are recognized as
"special" by several Macintosh terminal emulators.
These emulators, using Kermit or Xmodem or other file
transfer protocols, can separate the incoming file into
forks and appropriately modify the Desktop to display
icons, types, creation dates, and the like.
BinHex 4.0:
A seven bit wide representation of a Mac file with CRC
error checking, BinHex 4.0 files are designed for
communication of Mac files over long distance, possibly
noisy, seven bit wide paths.
PackIt:
PackIt files are actually representations of
collections of Mac files, possibly Huffman compressed.
Packing many small related files together before a
MacBinary transfer or a translation to BinHex 4.0 is
common practice.
Text:
A Macintosh ends each line of a plain text file with a
carriage return character (^M), rather than the newline
character (^J) that some systems seem to prefer.
Moreover, a MacBinary file has prepended Finder
information that non-Macintoshes don't need.
Data, Rsrc:
A Data or Rsrc file is the exact copy of the data or
resource fork of a Macintosh file.
FORMAT OPTIONS
Exactly one of the following selections may be specified for
an input name:
x BinHex 4.0 - files in the MacBinary format are
Page 2 (printed 1/23/96)
MCVERT(LOCAL) UNIX System V (25Sep92) MCVERT(LOCAL)
translated to BinHex files, or vice versa. The name
argument may be the name of a file to be converted or a
basename to which an appropriate suffix must be
appended to get a filename. If the conversion is from
BinHex 4.0 to MacBinary, several files may comprise the
BinHex representation of the Mac file. Rather than
manually concatenate the files and manually delete mail
headers and other extraneous garbage, one may specify
the names of the files in order and mcvert will do the
concatenating and deleting. Conversely, in converting
a MacBinary file to BinHex 4.0 format for mailing over
long distances, one may be restricted to mail messages
of no greater that some fixed length. In this case,
mcvert can automatically divide the BinHex file into
pieces and label each piece appropriately. For details
on automatically segmenting files, see the description
of the MAC_LINE_LIMIT environment variable below.
r Resource - files in the MacBinary format with empty
data forks and nonempty resource forks are made from
ordinary data files, or vice versa.
d Data - files in the MacBinary format with nonempty data
forks and empty resource forks are made from ordinary
data files, or vice versa.
u | h
Text - files in the MacBinary format with nonempty data
forks and empty resource forks are made from ordinary
data files, or vice versa. The newly created MacBinary
file has creator field given by the MAC_EDITOR
environment variable. Option 'u', for usual, performs
conversion. Option 'h', for host, performs no
conversion. When converting, Unix newline characters
are interchanged with Macintosh carriage return
characters.
ENVIRONMENT VARIABLES
There are four environment variables one may use to
customize the behavior of mcvert slightly.
MAC_EDITOR
The creator of MacBinary text files produced with
options -uD. The default is MACA, the creator type of
MacWrite.
MAC_DLOAD_DIR
The MacBinary files created when option -D is selected
are placed in this directory. The default is ".", the
current working directory.
MAC_EXT
Page 3 (printed 1/23/96)
MCVERT(LOCAL) UNIX System V (25Sep92) MCVERT(LOCAL)
The MacBinary files created when option -D is selected
are named according to the filename field stored in the
file header, with the name extended by this suffix.
The default is ".bin".
MAC_LINE_LIMIT
The BinHex files created when option -U is selected may
be no longer than this many lines long. Files that
would otherwise exceed this line limit are broken up
into several files with numbers embedded into their
file names to show their order. Each such file has
"Start of part x" and "End of part x" messages included
where appropriate.
BUGS
mcvert silently discards input lines which are not
completely valid. Therefore, error indications for
illegally formatted files are likely to be somewhat obtuse,
often with just a CRC mismatch message.
In order to handle files (such as segmented
comp.binaries.mac files) which have extraneous but valid
BinHex 4.0 lines (such as "---"), mcvert uses the following
heuristic to discard suspect but legal lines in BinHex 4.0
formatted input files. When a new file is opened, or when
invalid lines are found, the search for good data begins.
While searching for good data, if a line is too short (less
than 12 characters), or if a line is just a single repeated
character, the line is discarded. Once mcvert starts
processing good data, no valid lines are discarded. Thus,
this heuristic can also discard (unusually formatted) valid
and intended BinHex 4.0 lines. While there is no way to
tune the heuristic (other than modifying the program and
recompiling), the heuristic can be completely disabled with
the -H option. So if you run into problems, put all the
relevant lines into one file, edit the file to remove any
extraneous lines, and invoke mcvert with the -H option.
It should be possible to discard bad input now and
successfully translate good input later, but bad input
sometimes just causes immediate termination.
A more diligent person would support BinHex 3.0 and BinHex
2.0 and BinHex 5000.0 B. C., but I've never seen anyone use
them in three years. A more diligent person would also do
something for users of macget and macput, but hopefully
someone will make those programs support the MacBinary file
protocol.
The rules for when files are suffixed with extensions like
.rsrc and .data are not obvious or are unreasonable. For
example, when converting from MacBinary to resource, data,
Page 4 (printed 1/23/96)
MCVERT(LOCAL) UNIX System V (25Sep92) MCVERT(LOCAL)
or text, the suffix is only appended if the non suffixed
version of the file is readable. This can lead to
anomalies. For example, if there is a file called foo.bin
which is the MacBinary representation for a file called foo,
and there is no file named foo, then the first mcvert -rU
foo will create foo, yet subsequent mcvert -rU foo requests
will create foo.rsrc.
SEE ALSO
xbin(1), macget(1), macput(1), xmodem(1), kermit(1)
AUTHORS
Doug Moore, Cornell University Computer Science. Based upon
xbin by Dave Johnson, Brown University, as modified by Guido
van Rossum, and upon unpit by Allan G. Weber, as well as
upon correspondence with several helpful readers of USENET.
Joseph P. Skudlarek (Jskud@std.mentorg.com) made numerous
enhancement and maintenance releases. Also, see the
comments in mcvert.c for additional supporting characters.
HOME Top of Help Desk Eye On The World The World Kiosk