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.