Provided by: manpages-ja_0.5.0.0.20110915-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 つまり、読んでも良いグルー
       プ  の所有とする。必要なら、この目的のための   新しいグループをつくるこ
       と。次に、/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)