Provided by:
manpages-ja_0.5.0.0.20080615-1_all 
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)