con, telnet, rx, hayes, xms, xmr – remote login, execution, and
XMODEM file transfer|
con [ –CdnrRsTv ] [ –b baud ] [ –l [ user ] ] [ –S svc ] [ –c cmd ]
telnet [ –dCrn ] [ –s svc ] [net!]machine
rx [ –eTr ] [ –l user ] [net!]machine [ command–word ... ]
hayes [ –pv ] number [ device ]
xms [ –1p ] file
Con connects to the computer whose network address is net!machine
and logs in if possible. With no options, the account name used
on the remote system is the same as that on the local system.
Standard input and output go to the local machine. |
The control–\ character is a local escape. It prompts with >>>. Legitimate
responses to the prompt are
Telnet is similar to con, but uses the telnet protocol to communicate with the remote machine. It shares con's –C, –d, –n, and –r options.
Rx executes one shell command on the remote machine as if logged
in there, but with local standard input and output. A rudimentary
shell environment is provided. If the target is a Plan 9 machine,
$service there will be rx. Options are:
Network addresses for both con and rx have the form network!machine. Supported networks are those listed in /net.
Hayes dials number on a Hayes–compatible modem, device. Under –p, it uses pulse dialing. Upon connecting, bytes are copied bidirectionally between the connection and standard input and output.
The commands xms and xmr respectively send and receive a single
file using the XMODEM protocol. They use standard input and standard
output for communication and are intended for use with con. The
–1 option to xms causes it to use kilobyte packet size of 1024
bytes. The –p option causes it to print a progress
message every ten kilobytes.
rx kremvax cat file1 >file2|
/sys/src/cmd/con for all other commands
cpu(1), ssh(1), telco(4)|
Con and telnet are merely obsolescent; the other commands are
obsolete and deprecated. |
Under rx, a program that should behave specially towards terminals may not: e.g., remote shells will not prompt. Also under rx, the remote standard error and standard output are combined and go inseparably to the local standard output. Rx will consume its standard input by copying it to the remote system, so redirect it from /dev/null if that's not what you want.
Rx does not normally encrypt its connection. An exception is when
it falls back to using ssh1(1).