Carousel Volume 2 #1/carousel.iso/mactosh/unix/unix_dow.doc

Text File | 1986-07-08 | 11.6 KB | 295 lines

 8-Jun-86 17:46:31-PDT,12145;000000000001
Return-Path: <[e-mail]>
Received: from sdcsvax.ucsd.edu by SUMEX-AIM.ARPA with TCP; Sun 8 Jun 86 17:43:44-PDT
Received: by sdcsvax.ucsd.edu (5.31/4.41)
    id AA29503; Sun, 8 Jun 86 17:44:58 PDT hops=0
Received: by sdcc3.ARPA (5.51/4.41)
    id AA02549; Sun, 8 Jun 86 17:44:47 PDT
Date: Sun, 8 Jun 86 17:44:47 PDT
From: [e-mail] (Chris Borton)
Message-Id: <[e-mail]>
Subject: Help article on Mac downloads (nroff)
Newsgroups: mod.mac
To: [e-mail]
Keywords: help Mac downloads

This is a document I wrote describing the different programs on Unix that aid
in downloading to the Macintosh.  I thought it might help some people
wondering what some of these programs are and other User Services personnel
that are often plagued with questions on how to use them.  The document is
written with simple nroff -ms commands; use
'[nt]roff -ms <whatever you save it as> to {view,print} it...

--Chris
-------
Chris Borton, UC San Diego Undergraduate CS; Micro Consultant, UCSD
[e-mail] || ...!{ucbvax,decvax,noscvax,ihnp4}!sdcsvax!borton
"Noch eine Woche, dann 'die Pruefungen,' und dann nach Davis bis 4 Aug wenn
 ich nach Goettingen fliegen werde.  Ich werde Euch sehr vermissen...es hat
 mir viel Spass gemacht und auch habe ich viel gelernt"
-----------------start article here-------------------
.ST
.PO 1i
.sp 2.5i
.B
.ce 4
.ps +6
Macintosh Transfers
.ps -6
.ul
by Chris Borton
.ul
U.C.S.D. Micro Computer Support Group
.sp 1.5i
.B
Introduction
.PP
Just as many of the micro computer users predecessing the Macintosh found,
there is a need to be able to transfer files composed of 8-bit bytes over
communication lines that only support 7-bits.  Most of these lines deal with
mainframes and other `older' machines, where there was only a need to
transfer text.  For this a 7-bit line is sufficient, but doesn't work for
8-bit `binary' (as opposed to text) data.  To handle this need, many
conversion protocols have been established; the standard for the
Macintosh is called `BinHex.'
.sp
.PP
This document will describe the process of converting a hex file on a
mainframe (presumed to be running Unix) and transferring it to a Macintosh in
a usable form.  The first portion will describe the `traditional' method,
which requires one of the commercial programs MacTerminal, VersaTerm,
SmartCom][, or MicroPhone.  Several programs to circumvent this and to
simplify some of the processes will be discussed afterward.
.PP
The Unix programs to be discussed are: macput, macget, xbin, macbin, and
unpit.  The principal programs on the Mac discussed are: BinHex, MacTerminal,
and PackIt.
.bp
.ti -.20i
.B
.ne 3
.ps +2
BINHEX
.ps -2
.PP
The key to most of this discussion is a program called BinHex for the
Macintosh.  Since programs and documents (other than text files) on the Mac
are made up of 8-bit bytes, and many communications channels only support
7-bit bytes, there was a need to be able to convert 8-bit material to 7-bits
for transfer, and convert it back once transferred.  BinHex is the program on
the Mac that does this conversion, in both directions.  It traditionally
produces <filename>\fI.hqx\fR as the BinHex version of <filename>.
.sp
.ti -.20i
.B
.ne 3
.ps +2
MACPUT
.ps -2
.PP
It is fairly simple to do the BinHex conversion on the Macintosh, and then
transfer the file via `traditional' means such as umodem/xmodem or
kermit.  The program MacTerminal came out early with the Mac, however,
and provided a feature for transferring files between two Macs hooked
up together.  When configured for two Macs running MacTerminal and
using the XMODEM protocol, the `Receive File...' menu item is
disabled.  If one Mac sends a file, the other automatically receives it
without any action on the part of the user.  Dave Johnson of Brown
University wrote the programs \fImacput\fR and \fImacget\fR for Unix to
`mimic' the actions of MacTerminal.  This allows Unix to transfer files
to the Macintosh in a relatively painless fashion.
.PP
The program \fImacput\fR makes Unix act as a Mac, running MacTerminal, that
has chosen `Send File...' from the `File' menu.  Given a filename, it sends
that Unix file to the Macintosh.  It has several options, the most important
of which is `-u.'  The command \fImacput -u\ <filename>\fR will send <filename>
to the Macintosh as a text file, doing the necessary conversions along the
way.  The command \fImacput\ <filename>\fR looks for three files:
<filename>.\fIrsrc,\fR <filename>.\fIdata,\fR and <filename>.\fIinfo\fR.  These
correspond to the resource and data fork on the Mac, as well as the Finder
info.  Knowledge of how these `sections' work is \fBnot\fR necessary to use
these programs effectively.
.sp
.ti -.20i
.B
.ne 3
.ps +2
MACSEND
.ps -2
.sp
.PP
\fImacsend\fR is a shellscript for Unix that will generate multiple
\fImacput\fR's.  The use of this is in transferring many files with
MacTerminal, where the command \fImacsend <file 1> <file 2> ... <file
n>\fR will transfer all those files without any action on the part of
the user.  This is particularly useful with wildcards, since all the
files to be downloaded can be `collected' into one directory and
\fImacsend *\fR will download all of them.
.sp
.ti -.20i
.B
.ne 3
.ps +2
MACGET
.ps -2
.PP
As a nice complement to \fImacput\fR, the program \fImacget\fR does the
opposite: act as a MacTerminal waiting to receive a file.  Although
MacTerminal is constantly in this `wait for a download' state, Unix is
not.  Hence, \fImacget\fR is necessary to put Unix in that state.  The
command \fImacget\fR is sufficient; it is unnecessary to give it a
filename since the MacTerminal sending the file informs the
`MacTerminal on the other side' (\fImacget\fR in this case) of the name
of the file.  This is the name of the file that appears on the Mac
screen in the box giving the name, size and percentage transferred.  If
given a filename, however, \fImacget\fR will discard the Mac filename
in favor of the one given it.  This program has the same set of options
as \fImacput\fR; they work basically in reverse.  One note:  \fImacget
-u <filename>\fR will take the file transferred as a text file,
converting it, and will add the suffix \fI.text\fR to the filename.
Given no options, \fImacget\fR will create three files:
<filename>\fI.rsrc, \fR <filename>\fI.data, \fR and
<filename>\fI.info\fR.  These can be sent the other direction using
\fImacput <filename>\fR.
.sp
.ti -.20i
.B
.ne 3
.ps +2
XBIN
.ps -2
.PP
Although the two programs \fImacput\fR and \fImacget\fR provide an nice
method of tranferring files between Unix and MacTerminal, the next step
is avoiding the BinHex process on the Macintosh.  The Unix program
\fIxbin\fR does the conversion \fBfrom\fR BinHex format \fBto\fR 8-bit
format on Unix.  Given a file <filename.hqx> (the .hqx suffix is
presumed but not necessary), \fIxbin <filename.hqx>\fR will produce
<filename>\fI.rsrc,\fR <filename>\fI.data,\fR and
<filename>\fI.info.\fR These are perfect for \fImacput\fR to download
to the Mac.  In the the case of an application program, once downloaded
it is ready to run.
.sp
.ti -.20i
.B
.ne 3
.ps +2
NET.SOURCES.MAC
.ps -2
.sp
.PP
One of the primary uses of this xbin/macput procedure is to take
advantage of the programs and information posted to net.sources.mac.
This article assumes basic knowledge of the news system.  The procedure
is fairly simple:
.sp
.in +0.75i
.ne 3
.ti -.20i
1. Save the program to your own directory from the news program.  (`s
<filename>' using \fIrn\fR)  This is necessary since xbin produces
files in the current directory; so write permission on the directory is
necessary.  An alternative to this is to use
\fIxbin\ /usr/spool/news/net/sources/mac/????\fR while in the directory
you wish the files to be in.
.sp
.ne 3
.ti -.20i
2. \fIxbin <filename>\fR   This will produce three files with the
suffixes \fI.rsrc, .data, and .info.\fR  Use `ls' to check what the
name is, since \fIxbin\fR restores the name used by the `creator' of
the file.
.sp
.ne 3
.ti -.20i
3. \fImacput <file>,\fR where <file> is the name before the suffixes
mentioned above.  i.e., <file>.rsrc, <file>.data, and <file>.info
should all exist.  If the file is a text file, use \fImacput -u
<file>\fR to transfer it.
.sp
.ne 3
.ti -.20i
4. MacTerminal will put up a window showing the name of the file, the
size, and what percentage has been transferred.  This will disappear
when completed; if there is an error, MacTerminal will alert that `File
Transfer Unsuccessful!'
.sp
.ne 3
.ti -.20i
5. Once successfully completed, the files on Unix may be deleted, if so
desired, and upon quitting MacTerminal the programs and/or files
transferred will show up on the disk, `ready to run.'  MacTerminal
places the files downloaded on the disk holding the MacTerminal
document that was opened.  Other programs vary\-see the next section on
`Other Programs For MacTerminal Transfers.'
.sp
.in -0.75i
.ti -.20i
.ne 3
.B
.ps +2
Other Programs For MacTerminal Transfers
.ps -2
.sp
.PP
There are several commercial terminal programs for the Macintosh that have
included `MacTerminal Transfers' in their reportoire of file transfer
protocols.  Currently (June 1986) those known are: VersaTerm, VersaTerm Pro,
SmartCom\ ][, and MicroPhone.  VersaTerm and VersaTerm Pro handle the
transfers similarly to MacTerminal.  VersaTerm 1.52 downloads files
onto the disk it was run from; VersaTerm 2.0 and VersaTerm Pro
allow the user to specify the `Receive Volume' from the `About
VersaTerm' menu.  SmartCom ][ forces you to give the file a name, and
does not accept the transfer `automatically'\-the user must specify
that a file is to be received.  MicroPhone has not been tested here,
but is believed to work in the same fashion as MacTerminal.
.sp
.ti -.20i
.B
.ne 3
.ps +2
PackIt and unpit
.ps -2
.sp
.PP
\fIPackIt\fR is a program to put several files together into one for
easy transfer.  This can greatly facilitate moving many small files,
since only one must be transferred.  This makes it easier to transfer,
but requires that the file be `packed' and `unpacked', thus adding
steps to the process.  There is a newer version, called
\fIPackIt\ II,\fR that does some compression of the file as well.  Use
of this format on Usenet is presently controversial since it is shareware,
not public domain.
.PP
Just as \fIxbin\fR does the job of BinHex, \fIunpit\fR does the job
of `unpacking' files on Unix.  The normal procedure is to
\fIxbin\fR\ <filename>, and then `\fIunpit\fR <filename>\fI.data.'\fR  This
will create all the original files, each with the appropriate
<file>.rsrc, <file>.data, and <file>.info.  These may then be downloaded with
\fImacput.\fR
.sp
.ti -.20i
.B
.ne 3
.ps +2
MacBinary and macbin
.ps -2
.sp
.PP
MacBinary is an 8-bit format developed for Bulletin Board Systems and
commercial services such as CompuServe.  It is  not useful for transfer
between most mainframes, since those connections are limited to 7
bits.  As a popular format that is included in many Macintosh
communications programs, however, its structure is similar to the
<filename>\fI.rsrc,\fR <filename>\fI.data,\fR and <filename>\fI.info\fR
files created by \fIxbin.\fR  Since they are similar, Jim Budler wrote
the program \fImacbin,\fR  that takes the three files created by
\fIxbin\fR and creates one file, <filename>\fI.bin,\fR which can be
transferred as a MacBinary file.  This is primarily to allow people to
use programs other than the commercial ones such as MacTerminal for
transfers.  Currently (June 1986) the public domain and shareware
programs known to support this are Red Ryder 5.0 - 9.2 (shareware) and
FreeTerm 1.7/1.8.  Commercial programs that support it are:
MacTerminal 2.0, VersaTerm and VersaTerm Pro, SmartCom ][ 2.1D,
MicroPhone, InTouch 2.0, and undoubtedly some others as well.