TIP(1) | User Commands | TIP(1) |
tip - connect to remote system
tip [-v] [-speed-entry] {hostname | phone-number | device}
The tip utility establishes a full-duplex terminal connection to a remote host. Once the connection is established, a remote session using tip behaves like an interactive session on a local terminal.
The remote file contains entries describing remote systems and line speeds used by tip.
Each host has a default baud rate for the connection, or you can specify a speed with the -speed-entry command line argument.
When phone-number is specified, tip looks for an entry in the remote file of the form:
tip -speed-entry
When tip finds such an entry, it sets the connection speed accordingly. If it finds no such entry, tip interprets -speed-entry as if it were a system name, resulting in an error message.
If you omit -speed-entry, tip uses the tip0 entry to set a speed for the connection.
When device is specified, tip attempts to open that device, but will do so using the access privileges of the user, rather than tip's usual access privileges (setuid uucp). The user must have read/write access to the device. The tip utility interprets any character string beginning with the slash character (/) as a device name.
When establishing the connection, tip sends a connection message to the remote system. The default value for this message can be found in the remote file.
When tip attempts to connect to a remote system, it opens the associated device with an exclusive-open ioctl(2) call. Thus, only one user at a time may access a device. This is to prevent multiple processes from sampling the terminal line. In addition, tip honors the locking protocol used by uucp(1C).
When tip starts up, it reads commands from the file .tiprc in your home directory.
-v
Typed characters are normally transmitted directly to the remote machine, which does the echoing as well.
At any time that tip prompts for an argument (for example, during setup of a file transfer), the line typed may be edited with the standard erase and kill characters. A null line in response to a prompt, or an interrupt, aborts the dialogue and returns you to the remote machine.
A tilde (~) appearing as the first character of a line is an escape signal which directs tip to perform some special action. tip recognizes the following escape sequences:
~^D
~.
~c [name]
~!
~>
~<
~p from [ to ]
cat > to
while tip sends it the from file. If the to file is not specified, the from file name is used. This command is actually a UNIX-system-specific version of the `~>' command.
~t from [ to ]
cat from; echo ^A
to send the file to tip.
~|
~C
~$
~#
~s
~^Z
~^Y
~?
Copying files requires some cooperation on the part of the remote host. When a ~> or ~< escape is used to send a file, tip prompts for a file name (to be transmitted or received) and a command to be sent to the remote system, in case the file is being transferred from the remote system. While tip is transferring a file, the number of lines transferred will be continuously displayed on the screen. A file transfer may be aborted with an interrupt.
tip may be used to dial up remote systems using a number of auto-call unit's (ACUs). When the remote system description contains the du capability, tip uses the call-unit (cu), ACU type (at), and phone numbers (pn) supplied. Normally, tip displays verbose messages as it dials.
Depending on the type of auto-dialer being used to establish a connection, the remote host may have garbage characters sent to it upon connection. The user should never assume that the first characters typed to the foreign host are the first ones presented to it. The recommended practice is to immediately type a kill character upon establishing a connection (most UNIX systems either support @ or Control-U as the initial kill character).
tip currently supports the Ventel MD-212+ modem and DC Hayes-compatible modems.
When tip initializes a Hayes-compatible modem for dialing, it sets up the modem to auto-answer. Normally, after the conversation is complete, tip drops DTR, which causes the modem to "hang up."
Most modems can be configured so that when DTR drops, they re-initialize themselves to a preprogrammed state. This can be used to reset the modem and disable auto-answer, if desired.
Additionally, it is possible to start the phone number with a Hayes S command so that you can configure the modem before dialing. For example, to disable auto-answer, set up all the phone numbers in /etc/remote using something like pn=S0=0DT5551212. The S0=0 disables auto-answer.
Descriptions of remote hosts are normally located in the system-wide file /etc/remote. However, a user may maintain personal description files (and phone numbers) by defining and exporting the REMOTE shell variable. The remote file must be readable by tip, but a secondary file describing phone numbers may be maintained readable only by the user. This secondary phone number file is /etc/phones, unless the shell variable PHONES is defined and exported. The phone number file contains lines of the form:
system-name phone-number
Each phone number found for a system is tried until either a connection is established, or an end of file is reached. Phone numbers are constructed from `0123456789−=*', where the `=' and `*' are used to indicate a second dial tone should be waited for (ACU dependent).
tip maintains a set of variables which are used in normal operation. Some of these variables are read-only to normal users (root is allowed to change anything of interest). Variables may be displayed and set through the ~s escape. The syntax for variables is patterned after vi(1) and mail(1). Supplying all as an argument to the ~s escape displays all variables that the user can read. Alternatively, the user may request display of a particular variable by attaching a ? to the end. For example, `~s escape?' displays the current escape character.
Variables are numeric (num), string (str), character (char), or Boolean (bool) values. Boolean variables are set merely by specifying their name. They may be reset by prepending a ! to the name. Other variable types are set by appending an = and the value. The entire assignment must not have any blanks in it. A single set command may be used to interrogate as well as set a number of variables.
Variables may be initialized at run time by placing set commands (without the ~s prefix) in a .tiprc file in one's home directory. The -v option makes tip display the sets as they are made. Comments preceded by a # sign can appear in the .tiprc file.
Finally, the variable names must either be completely specified or an abbreviation may be given. The following list details those variables known to tip.
beautify
baudrate
dialtimeout
disconnect
echocheck
eofread
eofwrite
eol
escape
etimeout
exceptions
force
framesize
halfduplex
hardwareflow
host
localecho
log
parity
none>
zero
one
even
odd
If the pa capability is present, parity is initially set to the value of that capability; otherwise, parity is set to none.
phones
prompt
raise
raisechar
rawftp
record
remote
script
tabexpand
tandem
verbose
SHELL
HOME
Example 1 Using the tip command
An example of the dialog used to transfer files is given below.
arpa% tip monet [connected] ...(assume we are talking to a UNIX system)... ucbmonet login: sam Password: monet% cat sylvester.c ~> Filename: sylvester.c 32 lines transferred in 1 minute 3 seconds monet% monet% ~< Filename: reply.c List command for remote host: cat reply.c 65 lines transferred in 2 minutes monet% ...(or, equivalently)... monet% ~p sylvester.c ...(actually echoes as ~[put] sylvester.c)... 32 lines transferred in 1 minute 3 seconds monet% monet% ~t reply.c ...(actually echoes as ~[take] reply.c)... 65 lines transferred in 2 minutes monet% ...(to print a file locally)... monet% ~|Local command: pr h sylvester.c | lpr List command for remote host: cat sylvester.c monet% ~^D [EOT] ...(back on the local system)...
The following environment variables are read by tip.
REMOTE
PHONES
HOST
HOME
SHELL
/etc/phones
/etc/remote
/var/spool/locks/LCK..*
/var/adm/aculog
~/.tiprc
There are two additional variables, chardelay and linedelay, that are currently not implemented.
November 28, 2001 | OmniOS |