This is tip3.man in view mode; [Download] [Up]
The program tip3 is a replacement for the tip that comes with the NeXT. It
includes a facility for doing xmodem, ymodem, and zmodem transfers by executing
the programs /usr/local/bin/sz and /usr/local/bin/rz, which can be gotten from
the next listings on BIX.
In addition, tip3 will recognize the start of a zmodem download (by looking for
the beginning of the ZRQINIT sequence ^XB0) and automatically start the rz
process. Thus, on BIX, one can give BIX the download command, and the download
of your SCRATCHPAD will happen automatically.
I wrote this utility primarily to communicate with BIX. I also wanted to get
experience with Objective-C. Tip3 was the first Objective-C program I wrote,
and has many things "hard-wired" that a truly friendly program would not. For
example, the programs (rz, sz) used to accomplish the file transfers must exist
in the /usr/local/bin/ directory. Also, the DELETE key is unconditionally
translated to backspace-space-backspace, so that the DELETE key will work
correctly on BIX.
I would most appreciate receiving any improvements made to tip3 (and I know
there is much room for improvement).
Installation of tip3 is like installation of other utilities, (simply copy it
into a directory in your PATH) except for one issue: the privilege of opening
the serial port. One way to obtain this privilege is for tip3 to have its
setuid bit set and to be owned either by root or by the owner of /dev/cub (uucp
on my system). The other way is to chmod the permission bits of /dev/cub so
that anyone can open it.
Following are usage notes:
SYNOPSIS
tip3 [file]
DESCRIPTION
Tip3 manages a full-duplex connection to a device, typically a modem.
During operation, characters typed are sent to the device and characters
received from the device are written to the screen.
Invoking tip3 without an argument will open the /dev/cub (Port B)
device at 2400 bps. With an argument tip3 will read and execute the
commands in the named file, a line at a time. The set of commands
will be described below. Most commands that can be executed from a
file can also be executed interactively by pressing ~ (tilde) followed
by a single character. In the following table the corresponding tilde
sequence is given in parentheses before the command name. Some
commands require more information, such as a file name or phone
number. When invoked interactively, these commands will prompt the
user. When invoked from a script file, the information must follow
the command as arguments. For example, to set the receive protocol to
zmodem, one would interactively type ~p, answer the first prompt with
"r" (for receive) and specify "z" for the protocol. In a script file,
one must write "protocol r z". The commands are:
(~^D) stop
Quit the program. This does not normally hang up the phone. In many
cases, the session can be restarted.
(~p) protocol
Set the file transfer protocols for sending or receiving files. The
program will prompt with
Enter direction [(s)end,(r)eceive]:"
for which protocol to set, and, after the user selects send or receive,
with
Enter desired send protocol [(x)modem,xmodem(1)k,(y)modem,(z)modem]:
Once the choice has been made, both send and receive protocols will be
displayed.
(~^P) parity
Set the parity to be sent to the remote host. Some hosts require even or
odd parity. BIX and most BBS's don't need any specific parity. This only
affects the parity of characters sent to the host; the parity of incoming
characters is ignored. The program will prompt with
Enter desired parity (even, odd, or none) [e,o,n]:
and will display the choice, once it has been made.
(~s) send
Send a file to the host using the currently selected "send protocol". The
program will prompt for a file, and will check for its existence. If the
file does not exist, the program will keep prompting until a good filename
is entered. Responding with just a return will abort the send.
After a valid file is established, the program will prompt for a command to
send to the host. This string (with the trailing "return") will be sent to
the host just before calling sz to perform the file transfer. Normally
this will be the command that would normally be typed to cause the host to
receive a file. The purpose of doing this is to avoid the several second
pause waiting for the host protocol program to time out.
An example upload, to BIX, is transcripted here (with annotations added):
--------comment---------------------
Rf: | BIX's prompt (user presses ~s) |
Enter file to send:comment | tip3 prompts for file (user enters |
| filename "comment") |
Enter command to send to host:up | tip3 prompts for host command (user|
| enters "up", the BIX command to |
| upload a file to the scratchpad |
------------------------------------
Sending comment, 8 blocks: Give your local XMODEM receive command now.
Sector 8 1k
------------------------------------
| The above is the output of sz, the |
| program that does the file transfer|
| |
File transfer process ended | tip3 gets control back from sz and |
| is back in its normal mode |
Rf: | BIX's prompt, after successful send|
------------------------------------
(~r) receive
Receive a file from the host using the currently selected "receive
protocol". If the receive protocol does not automatically obtain the file
name as part of the process, a file name will be prompted for.
The command to cause the host to send the file should be typed in prior to
executing the receive command of tip3. This is in contrast to the "send"
command.
(~c) capture
This toggles capture mode. When capture mode is on, all characters sent
from the host are captured in a file as well as being displayed on the
screen. Turning this on will prompt for a file name for capturing. The
default is "tip.record".
If the given file already exists, then the current session is appended to
it. So it is safe to specify the same file over multiple sessions, or to
put a "capture fixed_filename" into a script.
(~h) hangup
This will attempt to hang up the phone, first by dropping DTR, then by
sending three tilde's (~~~), pausing, and issuing the Hayes command ATH0.
This Hayes sequence is entirely hardwired.
(~e) readscript
This reads and executes a script file (the e is for execute). The file
name will be prompted for. One script can call another.
(~b) baudrate
This allows the user to set the transmission speed of the serial port. The
supported speeds are, in bits per second: 300, 1200, 2400, 4800, 9600.
echo
This will write the arguments to the screen. This might be useful for
status messages. Not very likely though.
say
This will send the arguments to the serial port, and thus either to the
modem or the remote host if the modem is "online".
(~d) dial
This command will prompt for a phone number to dial. It assumes, like the
hangup command, that the modem accepts Hayes "AT" type commands, and
generates Hayes "verbose" responses (CONNECT, CONNECT 1200, CONNECT 2400,
NO CARRIER, BUSY, NO DIALTONE). If the response from the modem is either
NO CARRIER or BUSY, then tip3 will pause a few seconds and try to dial
again. If the response is one of the CONNECT ones, tip3 rings the
terminal's bell.
To stop the redialing, press the ESCape key while tip3 is waiting for one
of the Hayes responses; tip3 will respond with "User aborted dialing" and
resume normal operations.
BUGS
Too many things are hard-wired, like the hayes commands and responses, the
serial port to use (/dev/cub), the location and name of the zmodem program, the
initial protocols (xmodem 1k for sending, zmodem for receiving).
Also, tip3 does not prevent other programs from opening the serial device, the
way tip does. It is possible to start one instance of tip3 while another is
running (say, from another Terminal). In such cases the output from the modem
gets split between the active tip3's. There is nothing to prevent different
users from running tip3 at the same time. This really should be fixed, so I'll
have to figure out someday how it is done.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.