.TH xchat 8 .SH NAME xchat - Extended chat processor .SH SYNOPSIS .BI "xchat " "scriptfile" .RI " [ " parameter... " ] " .PP where .I scriptfile is the name of a file containing an .I xchat script. If .I scriptfile begins with ``/'', then it is assumed to be a full path name for the script file. If not, a configuration-dependent default directory path (usually .B "/usr/local/conf/uucp/" ) is prepended to the script file name. Normally, the default path is the same as that for the Taylor UUCP configuration files. .SH DESCRIPTION .I Xchat is a general-purpose dialing and login program designed for use with Taylor UUCP as a ``chat-program'', taking the place (or augmenting) the built-in chat scripting facility. It provides the ability to closely control timeouts, multiple simultaneous ``expect'' strings with separate actions, extended terminal control, modem command character pacing, and more. .PP When used in conjunction with Taylor UUCP's configuration features, .I xchat can provide you the ability to manage the most intricate login, dial and hangup needs. The scripts are written in a shell-like (well, sort-of) style with labels, commands, and parameters, easing the task of writing procedures for complex terminal communications situations. .PP Because .I xchat assumes that it is connected to the terminal device via stdin/stdout, you can easily debug scripts by invoking it from the shell and responding to the script from the keyboard. A debug logging facility is included, with the debug output going to a separate user-specified file. This makes it easy to debug connection problems without wading through large .I uucico log and debug files. .PP Formally, a script describes a state machine; .I xchat interprets the script and does what the state machine tells it to. This section will be much easier to understand if you obtain listings of the script files supplied with .I xchat. .SH "SCRIPT FILE FORMAT" Script files are ordinary text files containing comments, labels, and statements. Blank lines are ignored. Comments are denoted by leading ``#'' characters. Some statements (those which do not end with an ``extended string'' argument; see below) can also have trailing comments. .PP .I Labels begin in column one and are ended by colons (:). A label specifies a state name. All lines between a pair of labels are the statements for a single state. .PP Processing always begins at the head of the script (no leading state name is necessary). .PP .I Statements are divided into two categories, ``action'' and ``expect''. When a state is entered, all of its actions are performed in the order in which they appear in the file. .PP A .I transition to another state may occur for any of three reasons: .IP (1) 5 One of the actions may cause a transition to another state, in which case the rest of the current state's actions are skipped. Processing resumes with the first action statement of the new state. .IP (2) 5 If none of the actions cause a state transition, and there are no expects in the state, processing ``falls through'' to the next state in the file. .IP (3) 5 If none of the actions cause a state transition, but there are expects in the state, the state machine pauses until one of the expects is ``satisfied''. It then transitions to the state named in the expect statement. .PP Finally, there are two action statements which, when executed, cause the script to exit. .SH "SCRIPT FILE STATEMENTS" This section describes all of the statements that may appear in script files, except for a few special action statements. Those are described in a later section, ``Overriding Defaults''. .PP Some statements accept one or two arguments, referred to in the following descriptions as .IR int ", " ns ", " str ", or " .IR xstr ", to" indicate whether the argument is an integer, a new state name, a string, or an ``extended string'' (described in a later section). .PP For all statements that accept two arguments, the first is the name of a new state, and the second specifies a condition or reason for changing to the new state. .SS "Termination And Informational Statements" These statements are used to place entries into the Taylor UUCP .I Log file, and to cause .I xchat to exit with successful or failure status. It is also possible to open a separate .I debug log file and control the level of tracing and error reporting that will go into that log file. This is very useful in debugging .I xchat scripts. .br .ta 1.0i 1.5i 2.0i .TP 2.0i .B failed Exit script with ``failed'' status. This causes .I xchat to exit with status 0. .TP 2.0i .B success Exit script with ``success'' status. This causes .I xchat to exit with status 1. .TP 2.0i .BI "log " xstr Send informational message .I xstr to standard error. When used with Taylor UUCP, this is the .I Log file for the .I uucico program. .TP 2.0i .BI "logerr " xstr Send message .I xstr to standard error, with ``ERROR:'' indicator. When used with Taylor UUCP, this is the .I Log file for the .I uucico program. .TP 2.0i .BI "dbgfile " xstr Open script debugging file .I xstr. If .I xstr begins with ``/'', it is assumed to be an absolute path name for the debugging file. If not, then a configuration-dependent default directory path (usually .B "/usr/spool/uucp" ) is prepended to .I xstr. Normally the default path is that of the directory where Taylor UUCP puts its log files. The debugging file is used to capture a detailed log of the data sent and received, errors encountered, and a trace of script execution. The various types of logging are controlled by the .I "debug mask," described next. .B Note: A new log file is created each time .I xchat runs. Use the .B log and .B loge commands to log continuous information onto standard out, which is connected to the Taylor UUCP .I Log file when .I xchat is run by the Taylor .I uucico. .TP 2.0i .BI "dbgset " int Set the bits specified in .I int in the debugging mask. The value in .I int is ``or''ed into the mask. Set bit 0 (value \= 1) for error messages, bit 1 (value \= 2) for dial, login and init errors, bit 2 (value \= 4) for dial, login and init trace with character I/O, and bit 3 (value \= 8) for script processing internals. Normally, you will just turn it all on with a value of 15. .TP 2.0i .BI "dbgclr " int Clear the bits specified in .I int from the debugging mask. .TP 2.0i .BI "debug " xstr Write .I xstr into the debug log. The entry will be enclosed in angle brackets. .TP 2.0i .BI "debuge " xstr Write .I xstr into the debug log with ``ERROR: '' prepended. The entry will be enclosed in angle brackets. .SS "Sending Data" These statements are used to transmit data to standard out (the tty or TCP port when used with Taylor UUCP). .I No implied carriage returns are sent. You must include a \\r if you want a carriage return in the string sent by the .B send command. If you want a return sent after .B dial or .B sendstr, you must send it with a separate .B send command. .TP 2.0i .B dial Send the string previously set by the .B telno command to the serial port. .B W and .B P characters in the phone number are converted as described under .B Dial Strings, below. This statement also sets a default timeout value, as described under the .B timeout statement. .TP 2.0i .BI "send " xstr Send the string .I xstr to the serial port. .TP 2.0i .BI "sendstr " int The argument of this statement is a digit from 0 through 7. Send the corresponding string parameter as passed to .I xchat following the script file name. The parameter is interpreted as an extended string. .SS "Special Terminal Control Statements" These statements are used to cause the terminal port to perform some special action, or to change the mode of the port. .I The modes of the port are restored to their original settings .I by xchat before it exits. .TP 2.0i .B flush Flush the terminal port's input buffer. .TP 2.0i .B break Send a break signal. .TP 2.0i .B hangup Momentarily drop Data Terminal Ready (DTR) on the serial port, causing the modem to hang up. (Not usually needed, since .I uucico does this at the end of each call.) .TP 2.0i .B 7bit Change the port to strip incoming characters to 7 bits. .I This is the default mode. This mode is implied when the port has parity enabled, since parity characters are 7-bits wide. .TP 2.0i .B 8bit Change the port to allow incoming 8-bit characters to be passed to the script processor. This mode has no effect if parity is enabled, since parity characters are 7-bits wide. .TP 2.0i .B nopar Change the port to 8-bits, no parity. .I This is the default mode. .TP 2.0i .B evenpar Change the port to 7-bits, even parity. .I Incoming characters with parity errors are discarded. .TP 2.0i .B oddpar Change the port to 7-bits, odd parity. .I Incoming characters with parity errors are discarded. .SS "Counting, Branching, Timing and Testing Statements" These statements are used to control the flow of the .I xchat script itself, including branching, delays, and counter manipulation. .TP 2.0i .BI "sleep " int Delay for .I int milliseconds. .TP 2.0i .B zero Clear the counter. .TP 2.0i .B count Add one to the counter. .TP 2.0i .BI "ifgtr " "ns int" Go to state .I ns if counter greater than .I int. .TP 2.0i .BI "goto " ns Go to state .I ns unconditionally. .TP 2.0i .BI "ifstr " "ns int" Go to state .I ns if string parameter .I int is nonempty. .TP 2.0i .BI "ifnstr " "ns int" Go to state .I ns if string parameter .I int is empty. .TP 2.0i .BI "ifblind " ns Change to state .I ns if the port is ``blind'' without carrier (CD) asserted. .I This is not yet implemented, the test always fails. .TP 2.0i .BI "ifblgtr " "ns int" Change to state .I ns if the port is ``blind'' without carrier (CD) asserted, and counter is greater then .I int. .I This is not yet implemented, the test always fails. .SS "Expect Statements" Expect statements are usually the last statements that appear in a given state, though in fact they can appear anywhere within the state. Even if they appear at the beginning, the script processor always does all of the action statements first. As a practical matter, the order of these statements is not significant; they are all interpreted ``in parallel''. .TP 2.0i .BI "expect " "ns xstr" Change to state .I ns if the string specified by .I xstr is received from standard input (usually the serial port). Case is significant, but high-order bits are not checked. .TP 2.0i .BI "expectstr " "ns int" Change to state .I ns if the string specified in parameter .I int is received from standard input (usually the serial port). .I int must be in the range 0 to 7. Case is significant, but high-order bits are not checked. Useful where a prompt can change in different dial-in lines. .TP 2.0i .BI "ifcarr " ns Change to state .I ns if Carrier Detect (CD) is true. .I Not currently implemented. Always changes state. .TP 2.0i .BI "ifhang " ns Change to state .I ns if a data set hangup occurs (SIGHUP signal received). .TP 2.0i .BI "timeout " "ns int" Change to state .I ns if the time (in milliseconds) given by .I int has elapsed without satisfying any expects. If the time specified is 0, a default timeout value (calculated from the length and other characteristics of the most recent dial string) is used. .SH "SCRIPT PROCESSING DETAILS" .SS "Extended Strings" In the statements that accept string arguments, the strings are interpreted as .I extended strings. Extended strings begin with the first nonblank character and continue, including all imbedded and trailing blanks and other whitespace, until (but not including) the end of the line in the script file. (There is no provision for line continuation.) No trailing spaces should be present between the last ``desired'' character of the string and the end of the line, as they will be included in the stored string and sent or expected, just as they appear in the script file. And, obviously, no trailing comments are permitted! They will just be stored as part of the string. .PP Within an extended string, the following ``escape sequences'' will be converted as indicated before being sent or expected: .br .nf .in +0.5i \fB\\d\fR EOT character (control-D) \fB\\N\fR null character \fB\\n\fR line feed \fB\\r\fR carriage return \fB\\s\fR space \fB\\t\fR tab \fB\\\-\fR hyphen \fB\\\\\fR backslash \fB\\ooo\fR character with value ooo (in octal) .in -0.5i .fi .PP Since extended strings in scripts can include embedded spaces, tabs, etc., these escape sequences are only required in strings appearing in systems entries, though they may be used in script files to improve readability. .PP The octal-character specification (\\ooo) may have from one to three octal digits; it is terminated either after the third digit or when a non-octal character is encountered. But if you want to specify one of these followed by something that happens to be a valid octal character (for example, a control-A followed by a 7) make sure to include all three digits after the \\ . So \\0017 would become a control-A followed by the Ascii character ``7'', but \\17 or \\017 would become a control-Y (decimal value 25). \\1S would convert to a control-A followed by an ``S''. .PP Extended strings are stored without a trailing carriage return unless one is explicitly present in the string (via \\r). .SS "String Parameters" The .B sendstr statement sends (after conversion from extended string format) one of the parameters given on the .I xchat command line following the script file name. The parameter is selected by the integer argument of the statement. .PP This allows ``generic'' script files to serve for many different systems; the string parameters provide the phone number, username, password, etc. Character substitutions described under ``extended strings'' above are performed on these strings. .PP The ifstr and ifnstr statements allow further generality in script files, by testing whether a particular parameter is present in the systems entry. For example, a single script can be used both for those systems that require a password and those that do not. The password is specified as the last argument in the .xchat command; the script can test for this parameter's existence and skip the password sequence if the parameter is empty. .SS "``Wait'' And ``Pause'' Characters In Dial Strings" An additional conversion is performed on dial strings. Dial strings are interpreted as extended strings. Then the characters .B W and .B P within a dial string are interpreted as ``wait for dial tone'' and ``pause'', and may be converted to other characters. By default, .B W is left alone, and .B P is converted to a comma (,); these are appropriate for Hayes-type modems. The script may specify other substitutions (see below). .PP .B NOTE: The Taylor UUCP documentation states that the ``wait'' and ``pause'' characters are ``='' and ``-'', respectively. These are actual characters understood by some modems. When using .I xchat you should put .B W and .B P in the dial strings you specify in the Taylor configuration files. This way, the .I xchat processor can make the substitution appropriate for the particular modem in use. Make a separate .I xchat script for each modem type, e.g., .I "dial.hayes" and specify the translation there. This way, the phone number strings in the Taylor configuration files can be used with a variety of modems. .SS "Default Timeouts For Dial Strings" When a .B dial statement is executed, a default timeout value is set. This is the timeout value used by a subsequent timeout statement if the statement specifies a timeout value of 0. .PP The default timeout is given by: .br .nf .in +2 \fIctime\fR + (\fIndigits\fR * \fIdgttime\fR) + (\fInwchar\fR * \fIwtime\fR) + (\fInpchar\fR * \fI ptime\fR) .in -2 .fi .PP where .I ndigits, nwchar, and .I npchar are the number of digits, wait characters, and pause characters in the dial string, and .I ctime, dgttime, wtime, and .I ptime are 45 seconds, 0.1 seconds, 10 seconds, and 2 seconds, respectively. All of these times may be changed as specified below under ``Overriding Defaults.'' .SS "Trailing Carriage Returns Not Assumed" In the .B dial and .B sendstr statements, the dial string or parameter is sent with no trailing carriage return; if a carriage return must be sent after one of these, a separate send statement must provide it. .SH "OVERRIDING DEFAULTS" The script processor sets several default values. The following statements, which override these defaults, may be useful in certain circumstances. .TP 2.0i .BI "chrdly " int Since many modems cannot accept dialing commands at full ``computer speed'', the script processor sends all strings with a brief inter-character delay. This statement specifies the delay time, in milliseconds. The default is 100 (0.1 second). .TP 2.0i .BI "pchar " str Specifies the character to which .BR P s in the dial string should be converted. Default is ``,'', for use with Hayes-type modems. .TP 2.0i .BI "ptime " int Specifies the time, in milliseconds, to allow in the default timeout for each pause character in the dial string. Default is 2000 (2 seconds). .TP 2.0i .BI "wchar " str Specifies the character to which .BR W s in the dial string should be converted. Default is ``W'', for Hayes modems. .TP 2.0i .BI "wtime " int Specifies the time, in milliseconds, to allow in the default timeout for each wait-for-dialtone character in the dial string. Default is 10000 (10 seconds). .TP 2.0i .BI "dgttime " int Specifies the time, in milliseconds, to allow in the default timeout for each digit character in the dial string. Default is 100 (0.1 second). .TP 2.0i .BI "ctime " int Specifies the time, in milliseconds, to allow in the default timeout for carrier to appear after the dial string is sent. Default is 45000 (45 seconds). .SH "SEE ALSO" uucico(8) for Taylor UUCP, and documentation for Taylor UUCP. .SH AUTHOR Robert B. Denny (email@example.com) .SH CONTRIBUTORS Daniel Hagerty (firstname.lastname@example.org) .SH HISTORY This program is an adaptation of the dial/login script processing code that is a part of DECUS UUCP for VAX/VMS, written by Jamie Hanrahan, et. al. .SH BUGS This version (1.1) does not support BSD terminal facilities. Anyone volunteer to add this?