home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / tcl / 2337 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  7.2 KB

  1. Path: sparky!uunet!dove!cme!libes
  2. From: libes@cme.nist.gov (Don Libes)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Expect: status report given and advice sought
  5. Message-ID: <20588@muffin.cme.nist.gov>
  6. Date: 11 Jan 93 21:27:16 GMT
  7. Organization: National Institute of Standards and Technology
  8. Lines: 195
  9.  
  10. A number of people have asked me about Tcl 6.5 and Expect.  No, they
  11. don't work together.  I believe John will issue another version (or
  12. patch) soon, so I'm not providing a patch for Expect until then.
  13.  
  14. I've completed revisions to Expect to make it work with Tk - I admit
  15. it - it was more work than I originally thought!  I've been getting
  16. pressure to use autoconf so I will probably try and integrate that
  17. before I officially release this new version.  At the same time, I
  18. figured I'd ask if anyone had any requests they've been holding back
  19. for reasons of not introducing incompatibilities - mainly because I
  20. want to introduce one...
  21.  
  22. In particular, I would like to remove the expect's ability to
  23. associate each action with lists of patterns.  Instead, each action
  24. will be limited to a single pattern.  "lists of patterns" are very
  25. confusing and it seems pointless since the "-re" option does a much
  26. better job providing alternation directly.  I should've removed it
  27. when the "-re" option was added, but I didn't realize at the time how
  28. efficient and easy regexps are.  (Yes, they have their quoting
  29. problems, too, but they're much more understandable.)
  30.  
  31. In part I suspect everyone feels similarly, but what I'm wondering is:
  32. do people have a significant investment in code that depends on the
  33. current syntax.  I've always imagined that most people immediately
  34. turn to regexp for even moderately complex patterns.
  35.  
  36. If this is the case, it may not bother many people at all.  Most
  37. simple things will work as before including:
  38.  
  39.     expect foobar
  40.     expect "foobar"
  41.     expect "foo\ bar"
  42.  
  43. However, some things won't work as before.  For example, the following
  44. will behave differently - now the braces will be considered as part of
  45. the pattern.
  46.  
  47.     expect "{foo bar}"
  48.  
  49. Here are my choices:
  50.  
  51. 0) I'd really like to dump the "list of patterns" feature entirely.
  52. However, if people feel strongly enough, I'm willing to do this:
  53.  
  54. 1) Users that want the old behavior must call expect_version with an
  55. appropriately-old version number.  Else you get the new behavior.
  56. This would allow at worst a one-line change to scripts.
  57.  
  58. 2) Have a flag (haven't thought of a good name yet) that says "the
  59. following token is a list of glob-style patterns".
  60.  
  61. 3) Both 1 and 2.
  62.  
  63. Note that I don't take this step lightly.  This will mean a change to
  64. the major version number of Expect (3 to 4).  John tells me that
  65. incompatibilities introduced by 7.0 may be very small, but it may make
  66. my indecision a moot point.
  67.  
  68. The remaining changes to Expect should not introduce any other
  69. incompatibilities.  Here's a quick summary:
  70.  
  71. New commands
  72. ------------
  73.  
  74. getpid        returns pid of current process.
  75.  
  76. send_log    Sends string to log file.
  77.  
  78. send_spawn    Alias for "send".  (Useful in environments where send
  79.         is already used (i.e., Tk).
  80.  
  81. Old commands - new functionality
  82. --------------------------------
  83.  
  84. spawn -noecho    Turns off echoing of spawn command and arguments to stdout.
  85.  
  86. interact    Now understand more than two processes, regexps, etc.
  87.         Details below.
  88.  
  89. The remainder of this covers changes to interact.
  90.  
  91. -re
  92.  
  93. The following pattern is used as a regular expression.  The
  94. side-effects are exactly as in "expect" except that the results are
  95. written to the array "interact_out".
  96.  
  97. Regular expressions will match the longest string received.  In
  98. particular, if a pattern can match the current input, it will do so
  99. even if it is possible to extend the match by waiting for future
  100. characters.
  101.  
  102. -input spawn_id
  103.  
  104. names a spawn_id from which to get input.  All following flags and
  105. patterns apply to this input until another -input flag appears.
  106.  
  107. Two -inputs are assumed, $user_spawn_id and $spawn_id.  If one -input
  108. is actually specified, it overrides $user_spawn_id.  If a second
  109. -input is specified, it overrides $spawn_id.  Additional -input flags
  110. may be specified.
  111.  
  112. -output spawn_id
  113.  
  114. directs all characters from the previous -input to the named spawn_id.
  115. Multiple -output flags can appear after a single -input in which case
  116. all characters are sent to all of the named spawn_ids.
  117.  
  118. If an -input flag appears with no -output flag, characters will be
  119. discarded.
  120.  
  121. The two implied -inputs default to having their outputs specified as
  122. $spawn_id and $user_spawn_id (in reverse).
  123.  
  124. If no -input appears, -output implies "-input $user_spawn_id".
  125. (Similarly, with patterns that do not have a -input.)
  126.  
  127. -echo
  128.  
  129. sends characters that match the following pattern back to the spawn_id
  130. that generated them as each character is read.  This may be useful
  131. when the user needs to see feedback from partially typed patterns.
  132.  
  133. Note that if a pattern is being echoed but eventually fails to match,
  134. the characters are sent to the spawned process.  If the spawned
  135. process then echoes them, the user will see the characters twice.
  136. -echo is probably only appropriate in situations where the user is
  137. unlikely to not complete the pattern.  For example, the following
  138. excerpt is from rftp, the recursive-ftp script, where the user is
  139. prompted to enter ~g, ~p, or ~l, to get, put, or list the current
  140. directory recursively.  These are so far away from the normal ftp
  141. commands, that the user is unlikely to type ~ followed by anything
  142. else, except mistakenly, in which case, they'll probably just ignore
  143. the result anyway.
  144.  
  145.     interact {
  146.         -echo ~g {getcurdirectory 1}
  147.         -echo ~l {getcurdirectory 0}
  148.         -echo ~p {putcurdirectory}
  149.     }
  150.  
  151.  
  152.  
  153. -flush
  154.  
  155. sends characters that match the following pattern on to the -output
  156. spawn_ids as characters are read.
  157.  
  158. This is useful when you wish to let a program echo back the pattern.
  159. For example, the following might be used to monitor where a person is
  160. dialing (a Hayes-style modem).  Each time "atd" is seen the script
  161. logs the rest of the line.
  162.  
  163.     proc lognumber {} {
  164.         interact -flush -f -re "(.*)\r" return
  165.         puts $log "[exec date]: dialed $interact_out(1,string)"
  166.     }
  167.  
  168.     interact -flush -f "atd" lognumber
  169.  
  170. -eof
  171.  
  172. is a special pattern matching EOF.  -eof applies to the most recent
  173. -input or -output, except when -eof precedes all -input and -output
  174. flags in which case it applies to all spawned process that do not have
  175. an -eof flag.
  176.  
  177. A default -eof is provided with the action "return", so that interact
  178. simply returns upon any EOFs.
  179.  
  180. -timeout <sec>
  181.  
  182. is a special pattern whose action is executed after <sec> seconds of
  183. no unread characters.
  184.  
  185. If -timeout precedes all -input flags, it applies to all -input
  186. flags, otherwise it applies to only the previous one.  -timeout
  187. applies to the most recent -input, except when -timeout precedes all
  188. -input flags in which case it applies to all spawned process that do
  189. not have an -timeout flag.
  190.  
  191. Using different timeouts could be used to autologout users who have
  192. not typed anything for awhile but who still get frequent system
  193. messages.  For examples:
  194.  
  195.     interact -input $user_spawn_id -output $spawn_id -timeout 3600
  196.  
  197. By default, there is no timeout.  The Tcl variable "timeout" has no
  198. affect on this timeout.
  199.  
  200. -i
  201.  
  202. Like other commands which take a -i flag, this introduces a
  203. replacement for the current spawn_id when no other -input or -output
  204. flags are used.
  205.