MCVERT

NAME

SYNOPSIS

DESCRIPTION

PARAMETERS

OPTIONS

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 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

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

x

BinHex 4.0 - files in the MacBinary format are 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

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

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, 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

AUTHORS

Joseph P. Skudlarek (Jskud@std.mentorg.com) made numerous enhancement and maintenance releases. Also, see the comments in mcvert.c for additional supporting characters.

Index

NAME

SYNOPSIS

DESCRIPTION

PARAMETERS

OPTIONS

FILE FORMATS

FORMAT OPTIONS

ENVIRONMENT VARIABLES

BUGS

SEE ALSO

AUTHORS