Provided by: manpages-ja_0.5.0.0.20080615-1_all bug

EXPECTト
       Expect                             について、直観的でない点が少しある。
       このセクションではそういったことの指摘とそれに対する示唆を試みる。

       共通の      expect     の問題は、シェルプロンプトを認識する方法である。
       その設定も、それを扱う人も、使うシェルもまちまちなので、実際に出てくる
       プロンプトを知らずに、汎用的に   rlogin  を自動化することは困難である。
       妥当な線は、ユーザーにプロンプトにマッチする正規表現(特にプロンプトの
       終りの部分)を環曲竸       EXPECT_PROMPT       に保存させることである。
       以下のようなコードででい襦                               EXPECT_PROMPT
       がなくても、コードは正しく動く可能世ある。

           set prompt "(%|#|\\$) $"          ;# default prompt
           catch {set prompt $env(EXPECT_PROMPT)}

           expect -re $prompt

       私としては、見えると思っているものの終りの部分を含んだ           expect
       パターンを書くように勧める。そうすれば、全体を見る前に応答を返してしまう
       ことを避けることがでい襦さらに、全体が見える前に答えることもでい襪
       その文字は質問に混ざって                                           echo
       される。言い替えれば、会話は正常だが見た目は 混ざって見える。

       ほとんどのプロンプトの終りの文字はスペースである。例えば、
       ftpからのプロンプトは、'f',  't',  'p',  '>'  そして  <blank>  である。
       このプロンプトにマッチさせるには、この文字の一つ一つにマッチしなければ
       ならない。blank を含めないのは、よくある誤りである。明示的に  blank  を
       入れるように。

       X*   の形のパターンを使うのであれば、*  はXから最後に受けとる何かまでの
       全てにマッチする。これは一見直観的だが、"最後に受けとる何か"が
       コンピュータの速度とカーネルとデバイスドライバによるI/O処理によって
       変わってしまうので混乱するだろう。

       特に、人間はプログラムの出力が巨大なひとまとまりとしてやってくると思いがち
       だが、実際には、ほとんどのプログラムは一行を一度に送る。
       こう仮定すると、直前の段落のパターンにあった    *    は、行の終りにしか
       マッチしないかも知れない。たとえ、もっと入力があると思われる場合でも
       出力を全て受けとった時点でしかマッチを行なわないのである。

       expect
       は、指定したパターンが教えてくれない限り、出力がさらにやってくるのか
       どうかわからない。

       行指向のバッファリングを行なっている場合ですら、犬い笋衒とはいえない。
       プログラムはバッファリングのタイプをめったに保証しないだけでなく、その際に
       消化不良を起こして出力行を中断し、行末をバッファ中のランダムな位置に
       置いてしまう。
       それで、パターンを書く時には、プロンプトの最後の何文字かを入れておいた方が
       犬い笋衒といえるのである。

       プログラムの最後の出力にあるパターンを待ち、実際には何がしか他のものが
       発行されている場合には      timeout       ァ璽錙璽匹波縦蠅垢襪海箸で-
       ない。理由は、   expect   が、タイムアウトしない   -  そのかわりに  eof
       を見つけられる                      -                      からである。
       代わりになるものを使うこと。もっと良いのは、両方使うことだろう。
       行が回り込んだ場合でも、行そのものを編集するべい任呂覆ぁ

       tty ドライバによって出力される時に newline  は、普通  carriage  return,
       linefeed                  の組に変換される。                  それで、2
       ラインにマッチするには、例えば、printf("foo\nbar")                   に
       マッチさせるには、"foo\r\nbar" というパターンを使うことになる。

       似たような変換は、ユーザーから                              expect_user
       を通して入力を読み込む時にも起こる。この場合、ユーザーがリターンを
       押すと、それは newline に変換される。その後、 Expect が端末モードを raw
       モード(telnet       のような)を設定すると、問題が発生する        可能-
       がある。プログラムが本当のリターンを待ってしまうからである。(プログラムの
       中には、newline
       をリターンに変えても大丈夫なものもあるが、ほとんどはだめである。)
       残念ながら、プログラムが端末を                                      raw
       モードにすることを検出する方法がない。

       手で             newline            をリターンに変えるのではなく、"stty
       raw"を使うのが解決策である。                  stty                  raw
       は、変換を停止する。しかし、こうすると    cooked   モードの行編集機能が
       使えなくなるということに注意すること。

       interact は、端末を raw モードに設定するので、この問題は発生しない。

       Expect
       スクリプトの中でパスワード(や他の機密情報)を保存すると便利なことは
       よくある。だれかのアクセスを受けるとその影響を受けてしまうコンピュータで
       そういうことをするのは勧められない。それで、パスワードのプロンプトを
       スクリプトから出すのが、文字通りパスワードを埋め込むよりは、良い考えと
       いえる。とはいうものの、そういった埋め込みをするしかない場合もある。

       不幸なことに、UNIX
       のファイルシステムは「実行可能で読めない」スクリプトを
       作る直接の方法がない。setgid
       シェルスクリプトをサポートしたシステムでは、
       次のようにすることで間接的にシミュレートでい襦

       ,           Expect           スクリプト(機密情報の入った)を普通に作る。
       そのパーミッションを   750   (-rwxr-x---)    に設定し、trusted    group
       つまり、読んでも良いグループ    の所佑箸垢襦I要なら、この目的のための
       新しいグループをつくること。次に、/bin/sh スクリプトを パーミッション
        2751 (-rwxr-s--x) で、同じグループの所佑悩鄒する。

       こうすると、シェルスクリプトはだれからも実行で(かつ、読め)る。
       実行すると、それは Expect スクリプトを実行する。

目
       Tcl(3), libexpect(3)
       "Exploring  Expect:  A  Tcl-Based  Toolkit  for  Automating Interactive
       Programs" by Don Libes,  pp.  602,  ISBN  1-56592-090-2,  O'Reilly  and
       Associates, 1995.
       "expect:  Curing  Those  Uncontrollable  Fits  of Interactivity" by Don
       Libes, Proceedings of  the  Summer  1990  USENIX  Conference,  Anaheim,
       California, June 11-15, 1990.
       "Using  expect  to  Automate System Administration Tasks" by Don Libes,
       Proceedings   of   the   1990   USENIX   Large   Installation   Systems
       Administration  Conference,  Colorado Springs, Colorado, October 17-19,
       1990.
       "Tcl: An Embeddable Command Language" by John  Ousterhout,  Proceedings
       of  the Winter 1990 USENIX Conference, Washington, D.C., January 22-26,
       1990.
       "expect: Scripts for Controlling Interactive Programs"  by  Don  Libes,
       Computing  Systems,  Vol.  4,  No.  2,  University  of California Press
       Journals, November 1991.
       "Regression Testing and Conformance Testing Interactive  Programs",  by
       Don  Libes,  Proceedings  of  the  Summer  1992  USENIX Conference, pp.
       135-144, San Antonio, TX, June 12-15, 1992.
       "Kibitz - Connecting Multiple Interactive Programs  Together",  by  Don
       Libes,  Software  -  Practice  &  Experience,  John  Wiley & Sons, West
       Sussex, England, Vol. 23, No. 5, May, 1993.
       "A Debugger for Tcl Applications", by Don  Libes,  Proceedings  of  the
       1993 Tcl/Tk Workshop, Berkeley, CA, June 10-11, 1993.

者
       Don Libes, National Institute of Standards and Technology

媼
       Tclを生み出した  John  Ousterhout  と、インスピレーションを与えてくれた
       Scott             Paisley              に感謝する。              Expect
       のオートコンフィギュレーションコードについて、 Rob Savoye に感謝する。

       HISTORY          ファイルに          expect          の進化の大部分が-
       述されている。このファイルは面白く読めて、かつ、
       あなたのこのソフトウェアへの洞察をより深くするだろう。このファイルに
       書かれている、私にバグフィックスを送ってくれた人たちや、他の援助を
       してくれた人たちに感謝する。

       Expect
       の設計と実装は、部分的にアメリカ政府からその対価をもらっているので、
       パブリックドメインである。しかし、このプログラムとドゥ絅瓮鵐箸△襪い
       その一部が使われたなら、著者と NIST への謝爾鮟劼戮討發蕕い燭ぁ

                               29 December 1994                      EXPECT(1)