home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / BEEHIVE / COMMS / QTERM42G.ARC / QTCHAT.DOC < prev    next >
Text File  |  1991-08-11  |  22KB  |  583 lines

  1. QTERM chat scripts
  2. ==================
  3.  
  4. A chat script is a means for getting QTERM to automatically send and
  5. receive text, this can be used to auto-dial, connect to remote systems,
  6. log in to them, and do whatever else is wanted. In addition, chat scripts
  7. have a number of commands available, to do such things as protocol sends
  8. and receives, transfer of text files, and many other things.
  9.  
  10. There are two ways of invoking a chat script. Firstly when QTERM is
  11. executed from CP/M, a chat script and parameters can be provided there:
  12.  
  13.     A>QTERM SCRIPT 1200
  14.  
  15. would be an example, alternatively the ^\ X command will prompt for a
  16. filename, the response can be exactly the same:
  17.  
  18.     Filename: SCRIPT 1200
  19.  
  20. will have the same effect.
  21.  
  22. QTERM will look in several places to try to find the script. The first
  23. thing it will do is to take the filename as given (subject to the
  24. current default drive/user, which may have been changed by the !n or
  25. ^\ N commands). If this is not successful, QTERM then searches the
  26. drive/user area that was active when it first started. It should be
  27. noted that if the entry subroutine includes BDOS calls to change either
  28. the drive or user, then the values rememberd by QTERM will be those on
  29. exit from the entry subroutine. This provides a mechanism for setting
  30. up a default script area, a place where QTERM will always try to find
  31. scripts. In addition, if it can't find the script as a file in the
  32. default script area, QTERM will look for a .LBR file /QTERM.LBR and
  33. see if this library contains the script. The reason behind this is that
  34. scripts tend be fairly small, and it is far more efficient to keep them
  35. all together in one .LBR, since this saves disk space. It goes without
  36. saying that QTERM cannot deal with squeezed or crunched scripts, they
  37. must be saved in the .LBR as pure ASCII text files.
  38.  
  39. When a chat script is running it can be terminated prematurely by typing
  40. ^X on the keyboard: this will return to normal terminal mode.
  41.  
  42. There are two types of lines in a chat script: send/expect lines, and
  43. command lines. Command lines are always started with a '!' character,
  44. any other character starts a send/expect line.
  45.  
  46. Looking first at send/expect lines, they can contain up to six fields,
  47. and the first two must be provided, even if they are empty. An example
  48. of such a line is:
  49.  
  50.     -AT\r-OK\r\n-3-2-3-0-
  51.  
  52. In this example the '-' (first character) is the delimiter used to
  53. separate fields. Any character can be used except for '!', but whatever
  54. character is chosen cannot appear in the strings. Also note that
  55. chosing a delimiter from the characters above 'z' in the ASCII character
  56. set (i.e. '{', '|', '}', and '~') has a special effect, which is explained
  57. below. Taking the fields in order they are SEND, EXPECT, TIME, TRIES,
  58. SUCCESS, and FAIL. SEND is a string that is transmitted by QTERM, so in
  59. the example above QTERM would transmit 'AT<carriage return>'. As was noted
  60. above, delimiters above 'z' have a special effect: they cause the SEND
  61. string to be written out slowly: there is a tenth of a second delay
  62. after each character. EXPECT is a string that QTERM is looking for in
  63. response to it's SEND string: so in the above example, QTERM would be
  64. looking for the 'OK<carriage return><linefeed>' that a Hayes compatible
  65. modem would respond with, when presented with 'AT<return>'.
  66.  
  67. The remining four fields are all decimal numbers, and can be omitted
  68. as QTERM will provide default values. TIME is the number of seconds
  69. to wait before assuming failure, if not given it defaults to 15. TRIES
  70. is the number of times to retry on failure, so taking our first example,
  71. TRIES is 2. If QTERM matched the EXPECT string on the first sending of
  72. SEND, all is well, but on the first failure it would resend the SEND string
  73. and look for the EXPECT string a second time. If it failed on this second
  74. attempt, only then would it consider this line to have failed. SUCCESS
  75. specifies the line number to transfer to in the chat script if it matched
  76. the EXPECT string. The default for this is the line following the current
  77. line. FAIL is the line to transfer to if the EXPECT string is not
  78. matched. This can be a line in the chat script, or as shown above 0 is
  79. allowed, which terminates the script immediately.
  80.  
  81. In the example above, the success and fail values are given as simple
  82. line numbers, it is also possible to use labels in chat scripts, see !:
  83. below for an explanation of how to define a label. If a label is being
  84. used, the line might look like this:
  85.  
  86.     -ATDT5551234\r-CONNECT-30--`connect-`fail-
  87.  
  88. In this case, the `connect and `fail are label usages, and cause transfer
  89. to wherever the corresponding label is. Using an undefined label does not
  90. directly cause an error, but the substitution of the label will usually
  91. create a line that cannot be parsed, thus flagging the error.
  92.  
  93. In another example, if the first line were:
  94.  
  95.     -AT\r-OK\r\n--5-
  96.  
  97. since TIME is empty, it defaults to 15, but as TRIES is 5, this line
  98. would try five times before giving up. Note also from this example
  99. that there are two ways of causing QTERM to default a value: an empty
  100. field (TIME) or end of the string (SUCCESS and FAIL). Note that the
  101. closing '-' after the 5 for TRIES is necessary. On the basis of this,
  102. the absulute minimum line is:
  103.  
  104.     -send-expect-
  105.  
  106. This uses all four defaults: 15 seconds timeout, 1 try, success goes to
  107. the next line, failure terminates the script. The idea behind these
  108. defaults is that a collection of simple send/expect lines like the above
  109. allow a "conversation" to be held with the remote system.
  110.  
  111. It is possible that either of SEND or EXPECT can be empty: an empty SEND
  112. causes nothing to be sent, but the EXPECT must be matched to continue;
  113. an empty EXPECT automatically matches. Note that if both are empty then
  114. the chat script will terminate when it reaches that line, so a line like:
  115.  
  116.     ---
  117.  
  118. will serve as a means to terminate a chat script, returning to terminal
  119. mode.
  120.  
  121. Command lines in chat scripts start with '!', and following the '!' is
  122. a command letter. If input is needed (e.g. for a '!b' or '!s' line)
  123. it should be placed after the command letter:
  124.  
  125.     !b 1200 8n1 -5 30 500 +\x13\x11
  126.  
  127. As is shown in the above example, spaces are permitted after the command
  128. letter, but not before.
  129.  
  130. Several of the ! commands correspond to ^\ commands available from terminal
  131. mode: the !b above would set the baud rate etc., just like the corresponding
  132. ^\ B command would.
  133.  
  134. Commands available in this group are:
  135.  
  136. !,    hangup
  137. !.    break
  138. !B    set baud rate
  139. !E    set local echo
  140. !H    set half duplex
  141. !J    toggle junking of control characters
  142. !L    set linefeed send for 'P'
  143. !M    set bit 7 mask
  144. !N    select new drive/user
  145. !V    toggle VT100 emulation
  146. !W    toggle split window mode
  147. !K    program function key
  148. !P    print file to remote
  149. !U    invoke user function
  150. !R    protocol receive
  151. !S    protocol send
  152. !X    activate chat script
  153. !Q    exit QTERM
  154.  
  155. Note also that the toggles ('!E', '!H', '!J', '!L', '!M', '!V' and '!W')
  156. behave a little differently. Since the state of these toggles is not defined
  157. when a chat script starts, with one exception (!W) there are three ways of
  158. invoking these. Using '!H' as an example:
  159.  
  160.     !h
  161.  
  162. behaves as would an <escape> 'H' in normal operation, i.e. it toggles
  163. the half duplex switch. However, if the following is given:
  164.  
  165.     !h 1
  166.  
  167. the trailing '1' forces half duplex to be enabled, irrespective of
  168. it's original state, and:
  169.  
  170.     !h 0
  171.  
  172. guarantees to turn half duplex off. The other toggles work in the same
  173. manner: a trailing '0' always disables, and a trailing '1' always
  174. enables. !W is a little different, in that there are three possibilities:
  175. window mode off, window mode on with big receive, and on with small. Also
  176. allowing a pure toggle could have undefined results, since if window mode
  177. were toggled on, there would be no indication what size was wanted. As
  178. a result of this, there are three forms for the !W command in a script:
  179.  
  180.     !w 0
  181.  
  182. forces window mode off,
  183.  
  184.     !w b
  185.  
  186. forces it on with a big receive window, and:
  187.  
  188.     !w s
  189.  
  190. forces it on, but with a small window. With all these toggles (!h etc. and
  191. !w) the options above are guaranteed, using any other option letters will
  192. have undefined results.
  193.  
  194. The 'X' command to activate a chat script can be used to chain scripts
  195. together: when an 'X' is encountered the specified chat script is
  196. invoked, however the current script is lost: it is overwritten by the
  197. new one.
  198.  
  199. There are other commands that are not normally available are as follows:
  200.  
  201.  
  202. !a - This simply alerts it's passing by ringing the terminal bell, this
  203. may be useful if a chat script is being used to repeatedly call a number
  204. until a connection is made: by putting a !a into the script, the
  205. system will beep when a connection is made.
  206.  
  207.  
  208. !f - Capture an ASCII text file. Since 'C' catch files are disabled during
  209. chat script operation, 'F' is provided as an alternative means for data
  210. capture. A typical 'F' line would be:
  211.  
  212.     !f b:catch.txt 6 string
  213.  
  214. This would open B:CATCH.TXT for output, then send 'string' out, and
  215. transfer all subsequent data to that file until a timeout of 6 seconds
  216. occurred. As with files opened by ^\ C, the specified file will be opened
  217. for append if it already exists, assuming it is writable. If it exists,
  218. but is read only, then QTERM will not do the open. 'string' is a string
  219. that can contain backslash escape sequences, just like a SEND string in
  220. normal chat operation. Any timeout can be given, up to about 250 seconds.
  221. Note that since this uses the same buffer as the <escape> C command, if
  222. there is already a catch file open, it will be automatically closed prior
  223. to execution of a '!f'.
  224.  
  225.  
  226. !: - Define a label. Label usage was described above: the '`' character
  227. introduces a label usage. To define a label, simply include a line of
  228. the form:
  229.  
  230. !: connect
  231.  
  232. in the script. A few comments may make labels easier to use, firstly
  233. they cannot be longer than seven characters, and where they are defined
  234. there should be no trailing blanks. When a label is used, it is done by
  235. means of a simple text substitution: after seeing a '`' character, QTERM
  236. tries to match the following text with a label in the script, and it
  237. stops at the first match. So if you have two labels one of which is a
  238. prefix of the other, the results can be unpredictable. As a byproduct
  239. of this, undefined labels do not generate an error (they just become
  240. line zero), but the text substitution doesn't remove the label, so the
  241. resulting line usually generates an error. In the event that a '`'
  242. character is needed as part of a send or expect string, it can be
  243. escaped by preceeding it with a $, so the line:
  244.  
  245.     .send.exp$`ect.
  246.  
  247. will look for exp`ect, whereas:
  248.  
  249.     .send.exp`ect.
  250.  
  251. will not work, it would try to look for and substitute the label 'ect'.
  252.  
  253.  
  254. The commands !@ and !# can be used for variable manipulation. Their
  255. main purpose is to prevent infinite loops in chat scripts. In the
  256. following example:
  257.  
  258.     !: reset
  259.     .AT\r.OK\r\n.5.5.
  260.     .ATDT5551212\r.CONNECT.30..`connect.`reset.
  261.     !: connect
  262.     . ........
  263.  
  264. if the system being called is off line and not answering, QTERM will
  265. loop here for ever. The !@ and !# provide the ability to keep count and
  266. terminate the loop after some specified number of tries.
  267.  
  268.     !@ var term +/- term
  269.  
  270. is the form of an @ line. var is a single letter variable (there are 26
  271. available: a through z), and term is either a number or a variable. This
  272. is very simplistic, in that two terms must be present: to set a variable
  273. simply say something like:
  274.  
  275.     !@ a 5 + 0
  276.  
  277. the operator can be either + or - and they act as you would expect. so:
  278.  
  279.     !@ a a - 1
  280.  
  281. will subtract 1 from a, or:
  282.  
  283.     !@ a a + b
  284.  
  285. will add b to a, etc. etc. Note that variables are recognised in either
  286. upper or lower case:
  287.  
  288.     !@ A a + B
  289.  
  290. would have exactly the same effect as the line above. Note that these are
  291. single bytes, so there is some risk of working with values above 255.
  292.  
  293. !# tests variables: the general syntax is:
  294.  
  295.     !# var operator term line
  296.  
  297. where var is a variable letter, term is a variable or a number, and the
  298. operator can be '=' to test for equality, '#' to test for inequality, '<'
  299. to check for less than and '>' to test for greater than. line is simply
  300. the line number in the script to go to is the test succedes. Note that this
  301. also provides a goto capability:
  302.  
  303.     !# a = a line
  304.  
  305. will always go to line, since a is always equal to itself. In this case,
  306. line can be a label usage:
  307.  
  308.     !# a = a `doit
  309.  
  310. All variables are initialized to zero when the first script in a series is
  311. invoked, but values are retained when a !x command chains from one script
  312. to another.
  313.  
  314.  
  315. Two commands have been added to manipulate the appearance of chat scripts:
  316.  
  317.     !> This is a line of text\r\n
  318.  
  319. !> simply prints the text, after processing '\' escapes. Note that
  320. leading and trailing spaces are ignored, so the above case would start
  321. with the 'T' of 'This'. In order to start or end with a with a space,
  322. \x20 can be used.
  323.  
  324.     !%
  325.  
  326. This command is actually several different commands rolled into one:
  327. !% o manipulates the echoing of characters received from the modem
  328. while the script is running:
  329.  
  330.     !% o 1
  331.  
  332. forces modem echo on,
  333.  
  334.     !% o 0
  335.  
  336. forces it off, and:
  337.  
  338.     !% o
  339.  
  340. simply switches state. In the same manner, !% m controls printout of
  341. the 'Match: OK' messages that are printed when QTERM matches the expect
  342. string in a send/expect line.
  343.  
  344.  
  345. As a complement to !>, teh !< command can be used to take keyboard input,
  346. and make decisions based on what happens. This includes four subcommands
  347. altogether:
  348.  
  349.     !< -
  350.  
  351. The '-' causes QTERM to prompt for a line of input using CP/M's BDOS
  352. buffered command. The line is then saved, and can be tested with the !< =
  353. command:
  354.  
  355.     !< = string line
  356.  
  357. If the input read in the !< - command is 'string' then transfer to line
  358. (which can be a label). Note that string is NOT processed for escapes,
  359. since the is intended only for printable ascii text comparisons.
  360.  
  361. This allows for such things as multiple choice:
  362.  
  363.     !> \r\nSelect system to call\r\n
  364.     !> 1. System 1 ..... \r\n
  365.     !> 2. System 2 ..... \r\n
  366.     !> 3. System 3 ..... \r\n
  367.     !: prompt
  368.     !> Enter 1, 2 or 3:\x20
  369.     !< -
  370.     !< = 1 `sys1
  371.     !< = 2 `sys2
  372.     !< = 3 `sys3
  373.     !> Error, invalid input\r\n
  374.     !# a = a `prompt
  375.  
  376. Where the first 4 lines print a menu, the next line defines a label. Then
  377. comes a prompt, followed by an input command. After this, the line is
  378. checked against 1, 2 and 3, and a jump is made to the appropriate label.
  379. If there is no match an error message is printed, and the !# a = a line
  380. is used as a goto, since a is always equal to a.
  381.  
  382. In a similar manner, '!< .' and '!< ,' provide "hot key" comparisons, the
  383. !< . command simply reads a single character from the keyboard, and !< ,
  384. compares against a single character value just like !< = does:
  385.  
  386.     !< , \r `return
  387.  
  388. would be the test for a hot key input of a single carriage return. Note that
  389. in this case, \ escapes are permitted.
  390.  
  391.  
  392. The ![ command provides a similar function to the !< command, but it
  393. works on text coming from the modem. There are three forms:
  394.  
  395.     ![ -
  396.  
  397. reads text from the modem. In this instance there are two ways that
  398. reading can end:
  399.  
  400.     ![ - 15
  401.  
  402. would simply read text for 15 seconds. This numeric timeout must be
  403. provided, but in addition up to four extra strings can be provided:
  404.  
  405.     ![ - 5 .string1.string2.string3.string4.
  406.  
  407. in which case input will terminate when 5 seconds have elapsed, or one
  408. of the four strings is read. In this line, the '.' following the 5 is a
  409. delimiter, this serves to separate the strings exactly like the delimiter
  410. in a send / expect line. Not all four strings need to be there:
  411.  
  412.     ![ - 5 .OK.ERROR.
  413.  
  414. is acceptable, but the trailing delimiter must be there after the last
  415. string. In addition to scanning for the four lines, QTERM keeps the last
  416. sixty-four characters seen in a buffer, these can then be inspected with
  417. ![ = and ![ + lines. These do very similar functions, in that they both
  418. look for a string in the last 64 characters seen.
  419.  
  420.     ![ = string line
  421.  
  422. searches the saved text for the string, which in this case can include
  423. \ escapes. If string occured anwhere in the last 64 characters, control
  424. goes to line. ![ + looks exactly the same, but the difference is whether
  425. the test is done on seven or eight bit data: ![ = just compares the least
  426. significant seven bits, ignoring the parity bit, whereas ![ + compares
  427. all eight. Note also that the strings provided in the ![ - line are only
  428. checked in seven bit mode.
  429.  
  430.  
  431. The !~ command has been added for rudimentary file manipulation
  432. during chat script operation. Three options exist:
  433.  
  434.     !~ - file
  435.  
  436. will erase a file. Note that QTERM will silently ignore this command
  437. if the file doesn't exist, or if it is write protected. As with all
  438. filenames, a drive/user can be given:
  439.  
  440.     !~ - d15:foo.bar
  441.  
  442. does like you'd expect.
  443.  
  444.     !~ = newname = oldname
  445.  
  446. renames a file: note that if a drive/user is given on oldname, it will
  447. be ignored: newname completely defines where the action will happen.
  448. This will fail silently if newname already exists, or if old name doesn't,
  449. or if oldname does exist but is write protected.
  450.  
  451.     !~ + newname = oldname
  452.  
  453. copies a file. In this case a file can be copied to a different
  454. drive / user, so if needed a drive / user spec should be attached to
  455. oldname. This will fail silently if newname exists or if oldname doesn't.
  456. These can be used to good effect when QTERM is sending text files as
  457. messages to a BBS, after sending the file with a !P command, a !~ - will
  458. erase it, or files can be erased after uploading, or a file might be
  459. renamed after a batch download.
  460.  
  461.  
  462. Parameters can be passed to chat scripts, in much the same way as to
  463. SUBMIT operation: invoking a script:
  464.  
  465.     SENDFILE b3:*.asm
  466.  
  467. where there is a line in it:
  468.  
  469.     !s xky $1
  470.  
  471. causes the line to become:
  472.  
  473.     !s xky b3:*.asm
  474.  
  475. Warning: when a script is invoked directly from CP/M the parameters will all
  476. be forced to upper case - this is a byproduct of the behaviour of the CCP.
  477. It is for this reason that variables are recognised in both upper and lower
  478. case: there are interesting things that can be done by mixing $n parameters
  479. and variables: more in a minute.
  480.  
  481. In some cases it may be desirable to set a default value for a parameter,
  482. a further line has been added to do this:
  483.  
  484.     !$n stuff
  485.  
  486. the '!' and '$' are just that, 'n' is the number of a parameter ('1'
  487. through '9') and stuff will become the default value. In the following
  488. case:
  489.  
  490.     !$3 default
  491.  
  492. if parameter 3 is not set (i.e. blank) it is expanded to default,
  493. otherwise it is left alone. This might be useful when using one script
  494. to call at one of several baud rates:
  495.  
  496.     CALLBBS 1200
  497.  
  498. could be done in conjunction with:
  499.  
  500.     !b $1 8n1 .....
  501.  
  502. inside CALLBBS. However if the script is invoked:
  503.  
  504.     CALLBBS
  505.  
  506. without a parameter, and the following line:
  507.  
  508.     !$1 2400
  509.  
  510. exists, then the baud rate in the !b command would default to 2400. In
  511. order for these default set commands to work, they MUST be provided in
  512. the correct sequence:
  513.  
  514.     !$2 something
  515.     !$1 hello
  516.  
  517. will do very strange things. Also skipping values will do unexpected things,
  518. as will putting spaces in the default string. A place where this can be used
  519. to good effect is a script chain that calls several BBS's. By running a
  520. variable from 0 to 25 to escape the infinte loop described above:
  521.  
  522.     !: reset
  523.     !@ a a + 1
  524.     !# a > 25 `exit
  525.     .AT\r.OK\r\n.5.5.
  526.     .ATDT5551212\r.CONNECT.30..`connect.`fail.
  527.     !: fail
  528.     .XXX\r.YYY.30.5.`reset.`reset.
  529.     !: connect
  530.  
  531. when time runs out, this jumps to exit. Now, consider the following:
  532.  
  533.     !$1 y
  534.     !@ n 26 + 0
  535.     !@ a $1 + 0
  536.  
  537. Taking these lines in order: the first defaults parameter 1 to y
  538. The second sets variable n to 26. The last sets a to the variable
  539. named by parameter 1, so if the script is invoked:
  540.  
  541.     CALLBBS N
  542.  
  543. $1 will be N, and the last line will set a to 26 (n + 0). So when
  544. control enters the loop above, a is already set to 26, and the script
  545. immediately goes to `exit, thus bypassing the board. However, if it
  546. is invoked as just:
  547.  
  548.     CALLBBS
  549.  
  550. $1 defaults to y, and line three sets a to 0, thus causing the BBS to
  551. be tried. By repeating this for several boards:
  552.  
  553.     CALLBBS Y N Y Y N
  554.  
  555. will call the first, third and fourth, but bypass two and five. VERY
  556. IMPORTANT NOTE: in a sequence of chat scripts, chained by the !x command
  557. the parameters are lost after the !x command. However, by saying
  558.  
  559.     !x script param1 param2 param3
  560.  
  561. parameters can be passed from one script to another, and indeed other
  562. parameters can be added, and some removed.
  563.  
  564. As is done with labels, $n parameters are handled by simple text
  565. substitution, so a little care will make their use easier. As was
  566. described above, '$' is used to escape '`' characters in strings, it is
  567. also used to escape itself. i.e. to actually place a '$' character in a
  568. string say '$$', so that:
  569.  
  570.     .send.exp$$ect.
  571.  
  572. would look for the string 'exp$ect'. There are only three things that
  573. can follow a '$' sign: either '$' or '`' for escaping purposes,
  574. and '1' through '9' for parameter substitution. Placing any other
  575. character after a '$' will have an undefined result.
  576.  
  577.  
  578. As a final note, any other command character is silently ignored,
  579. this can be put to use to introduce comments. At this stage, !; is
  580. not in use, and this is the official comment entry, it is guaranteed
  581. that !; will never be used for a command line function in a QTERM
  582. chat script.
  583.