home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / tcl / 1908 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  2.1 KB
  1. Path: sparky!uunet!dove!cme!libes
  2. From: libes@cme.nist.gov (Don Libes)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Re: Expect: Why doesn't interact have the -re flag?
  5. Message-ID: <20225@muffin.cme.nist.gov>
  6. Date: 20 Nov 92 19:06:30 GMT
  7. References: <1992Nov16.023611.24765@midway.uchicago.edu>
  8. Organization: National Institute of Standards and Technology
  9. Lines: 47
  10.  
  11. In article <1992Nov16.023611.24765@midway.uchicago.edu> pynq@midway.uchicago.edu writes:
  12. >I would like to be able to either match strings with reg exps in
  13. >interact (and be able to check back to see exactly what was matched)
  14. >a la expect (with -re).  I could see no way to do this.
  15.  
  16. I'm actually working on this right now.  It's tricky because you have
  17. to consider the possibility of matching if more characters might
  18. arrive later.  Interact already does this with fixed strings, but it's
  19. more challenging with regular expressions.
  20.  
  21. Imagine the pattern "a.*c|b" with input of "ab".  With the "usual"
  22. regexp interpretation, this would match the second branch.  However,
  23. if we waited for a "c" to arrive, then the first branch would match.
  24. Note that the first branch starts earlier than the second branch.
  25. Does this mean the "might match" is preferable to the "match"?  Before
  26. you say "the match is always preferable", think about other examples.
  27. Consider all the useless computation that might take place should no
  28. match actually occur after a "might match".  Maybe we should just stop
  29. after the first "might match".
  30.  
  31. For now, I'm taking the approach that the earliest branch is best
  32. whether or not it is "match" or "might match".
  33.  
  34.  
  35. This work is part of a complete rewrite of "interact".  The new one
  36. will support the following:
  37.  
  38. m-to-n mapping of sources to sinks
  39. optional echoing of patterns
  40. regexp patterns
  41. timeout/eof patterns for each source
  42. Am I leaving out anything?
  43.  
  44. >Alternatively, if I could do an explicit I/O that would work, too, a la:
  45. >
  46. >interact {
  47. >    -o foo    { somekindofreadstmthere spawn_id var
  48. >        if {var == "bar"} ...
  49. >        if {var == "d"} ...
  50. >        }
  51. >    }
  52. >
  53. >Well, you get the idea...
  54.  
  55. You can do this.  Just use an "expect" to do your "somekindofreadstmthere".
  56.  
  57. Don
  58.