.\"
.\" Japanese Version Copyright (c) 1998 Hidefumi Yab 
.\"         all rights reserved.
.\" Translated Sat Jun 12 13:47:08 JST 1999
.\"         by Hidefumi Yab (yabide@da2.so-net.ne.jp)
.\" Updated Tue Jul  8 JST 2003 by Kentaro Shirakata <argrath@ub32.org>
.\"
.TH EXPECT 1 "29 December 1994"

.SH 名前
expect \- 対話的なプログラムとのやりとりを自動化するプログラム, バージョン 5


.SH 書式

.B expect
[
.B \-dDinN
]
[
.B \-c
.I cmds
]
[
.BR \- [ f | b ]
]
.I cmdfile
]
[
.I args
]

.SH イントロダクション
.B Expect
は、スクリプトの指示に従って、対話的なプログラムと"会話"するプログラムである。
以下のスクリプトに示すように、
.B Expect
には、対話プログラムからの期待されうる入力とそれに対する正しい応答を
教えておく。インタプリタは分岐処理と高度な制御構造を提供し、
対話プログラムへの指示を行なう。
さらに、必要な時にスクリプトから制御を奪って直接人間が指示を行ない、
その後、制御をスクリプトへ戻すことができる。

.PP
.B Expectk
は
.B Expect
と
.BR Tk
の混合物である。
.B Expect
であり、かつ、
.BR Tk 's
.BR wish
であるかのように振舞う。
.B Expect
は、C あるいは C++ (つまり、Tcl 以外)から、直接使うこともできる。
libexpect(3)を参照。
.PP
"Expect"という名前は、uucpで有名になった
.I send/expect
の概念に由来する。
(kermitや他のモデム制御プログラムでも、この概念は使われている)
しかし、uucp とは違って
.B Expect
は一般化されているので、想像されるどんなプログラムやタスクに対しても
マクロコマンド(user-level command)として機能できる。
.B Expect
は、同時に複数のプログラムと会話することができる。
.PP
.B Expect
にできることの例をいくつか挙げておく:
.RS
.TP 4
\(bu
電話代を払わずにログインできるようにコンピュータからあなたに電話を掛け直させる。
.TP
\(bu
ゲーム(例えば rogue)を始める時に、最適なパラメタがもらえなかった場合
最適なパラメタがもらえるまで何度でもリスタートを行ない、その後制御を人間に移す。
.TP
\(bu
fsckを走らせた時に現れる質問に、前もって決めておいた方針に従って、
"yes", "no", "手入力"を切替えて、返答する。
.TP
\(bu
他のネットワークや BBS(例えばMCI Mail, CompuServe)に接続した時に
自動的にメールの取り込み、発信を行なう。
.TP
\(bu
環境変数、カレントディレクトリ、その他の情報を、rlogin, telnet, tip, su, \
 chgrp などを行なった先へ持っていく。
.RE
.PP
これらの処理をシェルが行なえない理由はたくさんある
(やってみればわかるだろう)。全部
.BR Expect
ならできる。
.PP
一般に
.B Expect
は、プログラムとユーザーのやりとりが必要なプログラムを走らせるときに
役に立つ。大事なことは、このやりとりがプログラムの性格を持っていると
いうことである。
.B Expect
は、必要ならユーザーに制御を返すこともできる(しかも、プログラムは
中断されない)。同様に、ユーザーは制御をいつでもスクリプトに返すことができる。

.SH 用法
.B Expect
は、
.I cmdfile
を読み込み、実行するコマンドのリストを得る。
.B Expect
は、#! 表記をサポートする OS で、先頭行に

    #!/usr/local/bin/expect \-f

と書いておいて実行させることもできる。
もちろん、パスは正確に
.B Expect
のある場所を指示していなければならない。
/usr/local/bin は、一例である。

.B \-c
フラグで、スクリプトを実行する前に、実行するコマンドを指示する。
コマンドはシェルに壊されないようにクオートしておくべきである。
このオプションは何回出てきても構わない。
複数コマンドを指示した場合は、セミコロンで連結されたコマンドのように
扱われる。
コマンドは現れた順に実行される。(Expectk では、
.BR \-command
と書く)
.PP
.B \-d
フラグで、デバッグ情報出力を有効にする。基本的に
内部のコマンド(例えば
.B expect
や
.BR interact )
の振舞いを報告する。
このフラグは"exp_internal 1"とスクリプトの先頭に書くのと同じことだが、
さらに
.B Expect
のバージョン番号も出力される。
(
.B strace
コマンドは、命令をトレースするのに便利である。
.B trace
コマンドは、変数値をトレースするのに便利である。)
(Expectk を使う時は、このオプションは
.BR \-diag
と書く。)
.PP
.B \-D
フラグで対話型デバッガを有効にする。整数値が続かなければならない。
値が 0 でないか、C が押されると、次の Tcl 処理の前でデバッガに制御が移る。
ブレークポイントにかかった時や他のデバッグ命令を実行した時も、同じである。
デバッガについての情報がもっと欲しければ、 README や下記の関連項目を読むこと。
(Expectk を使っている時は、このオプションは
.BR \-Debug )
.PP
.B \-f
フラグで、コマンドを読んでくるファイルを指示する。このフラグは
あってもなくても良いのだが、#! 表記と一緒に使うと
引数からプログラム名を除けるから、その場合意味がある。
(Expectk では
.BR \-file )
.PP
デフォルトでは、コマンドファイルがメモリに一度に読み込まれ、そこで実行される。
一行ずつコマンドファイルを読んだ方が望ましい場合もある。例えば、
標準入力はこのように扱った方が良い。強制的にこのモードを指定するには、
.B \-b
フラグを指定する。
(Expectkでは、
.BR \-buffer )
stdio のバッファリングは依然有効であるが、FIFO または stdin から読み込む場合は
問題は起こらないはずであることに注意すること。
.PP
"\-"がファイル名として渡されると、標準入力からスクリプトが読み込まれる。
(本当に"\-"と言うファイルが読みたければ、"./\-"と書くこと)
.PP
.B \-i
フラグを指示すると、
.B Expect
はファイルからスクリプトを読まずに対話用プロンプトを表示する。
.B exit
コマンドか、EOF を受けるとシェルを終了する。
詳細については
.B interpreter
(下記) を参照のこと。
.B \-i
を指定した場合には、
コマンドファイルも
.B \-c
も指示されなかったものとして実行される。
(Expectkでは
.BR \-interactive )
.PP
.B \-\-
は、オプションの終りを区切るのに用いられる(省略可能)。これは、あなたが
オプションタイプの引数を
.BR Expect
に解釈させないで、スクリプトにそのまま渡したい時に役に立つ。
#! 行にこれを置いて、Expect にオプションとして解釈させないようにするこ
とができて便利た。

例えば、以下のように書くと(スクリプト名も含めて)オリジナルの引数は、変数
.IR argv
に残される。

    #!/usr/local/bin/expect \-\-

#!行に引数を加えると、通常の getopt(3) や execve(2) ではその引数が見えてしまう
ことに注意すること。
.PP
.B \-N
フラグを用いない限り、ファイル $exp_library/expect.rc が(あれば)自動的に
実行される。
(Expectk では、
.BR \-NORC )
.B \-n
フラグ
(Expectk では、
.BR \-norc )
を用いない限り、
続いて、ファイル ~/.expect.rc が、自動的に実行される。
環境変数 DOTDIR が定義されていれば、そこが .expect.rc のあるディレクトリ
として扱われる。

この二つのrcファイルの実行より先に
.B \-c
フラグで指示されたコマンドが実行される。
.PP
.B \-v
フラグを指示すると、バージョン番号を表示して終了する。
(Expectkでは、\-version)
.PP
オプション
.I args
は、リストに変換されて、変数
.IR argv
に保存される。
.I argc
は、argv のリスト長(要素の数)に設定される。
.PP
.I argv0
は、スクリプト名に設定される(スクリプトを使っていなければ、
バイナリの名前になる)。
例えば、以下のスクリプトを実行すると、スクリプト名と最初の引数3つを表示する:
.nf

    send_user "$argv0 [lrange $argv 0 2]\\n"

.fi
.SH コマンド
.B Expect
は、
.I Tcl
(Tool Command Language)を使用している。
Tcl は、制御フロー(例えば if, for, break)、式評価、および、
再帰やプロシジャ定義等他のいくつかの機能を提供する。
ここで使われているのに定義がないコマンド(例えば、
.BR set ,
.BR if ,
.BR exec )
は、Tcl コマンドである。(tcl(3)を参照)。
.B Expect
は、以下に記述する追加コマンドをサポートする。
記述がない場合は、そのコマンドは空文字列を返す。
.PP
コマンドは探しやすいようにアルファベット順に並べてある。
しかし、初めて使う方は、最初に
.BR spawn ,
.BR send ,
.BR expect ,
.BR interact
の説明をこの順番で読んだ方が分かりやすいだろう。

この言語(Expect と Tcl の両方)へのイントロダクションとしては、
"Exploring Expect"という本(関連項目を参照)がベストである。
このマニュアルページはリファレンスとして書いているので、
含まれている例は非常に限られている。注意すること。

このマニュアルページで、大文字の"E"で"Expect"とあれば、それは、
.B Expect
プログラムを指し、一方小文字の"e"で"expect"とあれば、それは、
.B Expect
プログラムに実装されている
.B expect
コマンドを指す。注意すること。
.I
.TP 6
.BI close " [-slave] [\-onexec 0|1] [\-i spawn_id]"
カレントプロセスへのコネクションをクローズする。
ほとんどの対話型プログラムが標準入力の EOF を検出し exit する。
それゆえ、
.B close
はそのプロセスを kill するのにも通常充分である。
.B \-i
フラグを指示すると、続く spawn_id を持つプロセスをクローズする。

.B expect
と
.B interact
は両方とも、カレントプロセスが exit した時点を検出して、明示しなくても
.BR close
を実行する。
しかし、"exec kill $pid" などのように、あなたがプロセスを kill している
なら、明示的に
.BR close
を呼ぶ必要がある。

.BR \-onexec
フラグを指示すると、新しい spawn が起きた時またはプロセスが重ねられた時に
前の spawn を閉じるべきかどうかを指示することができる。
前の spawn id で開いたままにしておきたければ、値 0 を用いる。
0 でない整数を指示すると、新しいプロセス中では前の spawn はクローズされる
(デフォルト)。

.B \-slave
フラグを指示すると、その spawn id の抱えているスレーブの spawn もクローズする。
("spawn -pty"を参照)
コネクションがクローズされると、スレーブはオープン状態であっても
クローズされる。

コネクションのクローズが明示されていたか否かに全然関わりなく、
関係するカーネルプロセススロットをクリアしてしまいたければ、
.B wait
を呼ぶこと。
.B close
は、
.B wait
を呼ばない。プロセスへのコネクションをクローズすると、そのプロセスが
exit するという保証がないからである。
もっと知りたければ、
.B wait
の項を参照すること。
.TP
.BI debug " [[-now] 0|1]"
は、Tcl デバッガを制御する。デバッガにより、ステップ実行、ブレークポイントの
設定などが行なえる。

引数がない場合、デバッガが走っていれば 1 を、そうでなければ 0 を返す。

引数が 1 なら、デバッガが起動される。引数が 0 なら、デバッガが停止する。
引数 1 の前に
.B \-now
フラグがあれば、デバッガは即座に起動される(つまり、
.B debug
コマンドそのものの途中で)。そうでなければ、デバッガは次の Tcl コマンドから
起動される。

.B debug
コマンドはトラップを変更しない。
.B -D
フラグをつけて起動させた場合とはそこが違う(上記参照)。

デバッガについては、README ファイルと関連項目を参照すること。
.TP
.B disconnect
fork されたプロセスを端末から切り離す。バックグラウンドで動作は続く。
プロセスは可能であれば自分自身のプロセスグループを与える。
標準入出力は、/dev/null にリダイレクトされる。
.IP
以下の断片は、
.B disconnect
を使って、バックグラウンドでスクリプトの実行を続ける。
.nf

    if {[fork]!=0} exit
    disconnect
    . . .

.fi
以下のスクリプトは、パスワードを読んで、一時間毎にパスワードを要求する
プログラムを実行する。スクリプトはパスワードを読み込んでいるので、
タイプするのは一回だけで済む。
(パスワードのエコーを避ける方法については、
.B stty
コマンドを参照)
.nf
    send_user "password?\\ "
    expect_user -re "(.*)\\n"
    for {} 1 {} {
        if {[fork]!=0} {sleep 3600;continue}
        disconnect
        spawn priv_prog
        expect Password:
        send "$expect_out(1,string)\\r"
        . . .
        exit
    }

.fi
シェルの非同期実行(&)時に
.B disconnect
を用いる利点は、
.B Expect
が disconnect の前に端末情報を保存しておいて、後で新しい pty にそのパラメタを
適用できる点にある。
& を使っていて
.B Expect
が制御を受けとって disconnect されてしまうと、端末情報を読み込むことはできない。
.TP
.BI exit " [\-opts] [status]"
.B Expect
を exit させるか、そのための準備を行なう。

.B \-onexit
フラグは、続く引数を exit ハンドラとして用いる。
引数がなければ、exit ハンドラは何もしない。

.B \-noexit
フラグを指定すると
.B Expect
は、exit の準備をして OS へ制御を返す直前に停止する。
ユーザーの定義した exit ハンドラは、Expect 自身の内部ハンドラと同じように
実行される。
それ以上 Expect のコマンドが実行されるべきではない。あなたが他の
Tcl Extension を Expect につけている場合にこの機能は意味がある。
Expect の
.B exit
がもう一度呼び出されると(こういう場合も起こり得る)、ハンドラは処理を
返さない。

exit する際に、全ての spawn されたプロセスへのコネクションはクローズされる。
クローズは EOF 検出によって行なわれる。
.B exit
は、普通の exit(2) が行なう以上のことはしない。
それで、spawn されたプロセスが EOF をチェックしない場合、そのプロセスは
走り続ける。(spawn されたプロセスへ送られたシグナルを判断するといったこと
には複数の条件が関わってくる。これらは、システム依存であり、典型的な動作は
各システムの exit(3) のドキュメントに記述されている。)

.I status
(指定がないときは、0 )は、
.BR Expect
の、終了ステータスとしてシステムに返される。
.B exit
は、スクリプトの終りに達すると、書いていなくても実行される、
.TP
\fBexp_continue\fR [-continue_timer]
.B exp_continue
コマンドは
.B expect
自身に待っていた値が来なかった時のように、expect の実行を続ける。
デフォルトでは
.B exp_continue
は時間切れタイマーをリセットする。
.I -continue_timer
フラグはタイマーを再実行しないようにする。
(より詳細な情報は
.B expect
を参照のこと。)
.TP
.BI exp_internal " [\-f file] value"
.I value
がゼロでなければ、以降のコマンドの診断情報を
.B Expect
内部の stderr に送るようになる。
.I value
に0を指定するとこの出力は止まる。この診断情報には、受けとった
すべての文字と、現在の出力とパターンをマッチさせる全試行が
含まれる。
.IP
.I file
オプションを指定すると、すべての通常および診断出力がそのファイルに
出力される。(
.IR value
の値とは無関係に)。すでにオープンされている診断出力ファイルは、
すべてクローズされる。

.B \-info
フラグは、最後に指定された info フラグでない引数の内容を返す。
.TP
.BI exp_open " [args] [\-i spawn_id]"
元の spawn id に結びつけられたファイル ID を返す。
そのファイル ID は、Tcl の
.B open
コマンドでオープンした時と同様に扱える。
(spawn id は、もう使われるべきでない。
.B wait
も実行すべきではない。)

.B \-leaveopen
フラグは、spawn id をオープンしたままにしておく。
.B wait
が、その spawn id に対して実行されねばならない。
.TP
.BI exp_pid " [\-i spawn_id]"
現在の spawn されたプロセスのプロセス ID を返す。
.B \-i
フラグを指示すると、与えられた spawn id に対するプロセスの ID を返す。
.TP
.B exp_send
.BR send
のエイリアス。
.TP
.B exp_send_error
.BR send_error
のエイリアス。
.TP
.B exp_send_log
.BR send_log
のエイリアス。
.TP
.B exp_send_tty
.BR send_tty
のエイリアス。
.TP
.B exp_send_user
.BR send_user
のエイリアス。
.TP
.BI exp_version " [[\-exit] version]"
は、スクリプトが現バージョンのExpectで動くことを確かめる時に役に立つ。
.IP
引数がなければ、
.B Expect
の現在のバージョンを返す。このバージョンはあなたのスクリプト内で
設定しても良い。あなたが最近のバージョンに入った機能を使わないの
であれば、もっと前のバージョンを指定することができる。
.IP
バージョンはドットで区切られた 3 つの番号である。
最初の番号は、メジャー番号である。
違うメジャー番号の
.B Expect
用に書いたスクリプトは、まず動かない。
.B exp_version 
は、メジャー番号がマッチしないとエラーを返す。
.IP
2 番めの番号はマイナー番号である。
使っている Expect よりマイナー番号がより大きい Expect 向けのスクリプトは、
新機能の使用未使用によるが、動かないかも知れない。
.B exp_version
はメジャー番号がマッチしてもマイナー番号が使っている
.BR Expect
のバージョンより大きいとエラーを返す。
.IP
3番めの番号は、バージョン比較には使われない。
しかし、文書の更新やプログラムの最適化が行なわれて、
.B Expect
のディストリビューションが更新されると、番号が増えていく。
新しいマイナーバージョンが設定される度に、0 にリセットされる。
.IP
.B \-exit
フラグをつけると、バージョンが合わなかった時に
.B Expect
はエラーを表示し exit する。
.TP
.BI expect " [[\-opts] pat1 body1] ... [\-opts] patn [bodyn]"
は、spawn されたプロセスの出力がパターンのどれかにマッチするか、
指定された時間が経過するか、enf-of-file を見つけるか、のいずれかが
成立するまでウェイトする。
最後の body が空なら、それは省略できる。
.IP
一番最後に実行された
.B expect_before
コマンドのパターンが、どのパターンより先にチェックされる。
一番最後に実行された
.B expect_after
コマンドのパターンが、どのパターンより後にチェックされる。
.IP
.B expect
全体への引数が 1 行に収まらなかった場合は、
引数を"ブレース"することで、各行の終りにバックスラッシュをつけるのを
避けることができる。この場合、ブレースしたにもかかわらず通常の Tcl 展開が
発生する。
.IP
もし、パターンがキーワード
.BR eof
であれば、end-of-file 発見時に処理が実行される。
もし、パターンがキーワード
.BR timeout
であれば、タイムアウトが発生した時に処理が実行される。
timeout キーワードが使われなかった場合、タイムアウト時にはなにもしない。
デフォルトタイムアウトは 10 秒である。設定することもできる。
例えば 30 秒と設定したければ、"set timeout 30"を実行すること。
タイムアウトさせないためには、値 \-1 を設定する。
もし、パターンがキーワード
.BR default
であれば、タイムアウトか end-of-file のいずれかで処理が実行される。
.IP
パターンにマッチすれば、処理は実行される。
.B expect
は、行なった処理(関連するブレース内の処理)の結果を返す。
(パターンにマッチしなかった時は、空文字列を返す。)
複数のパターンにマッチした場合、最初にマッチしたパターンに対応する処理が
実行される。
.IP
対話型プログラムからの新しい出力が Expect に届くたびに、リストされている順に
パターンとの比較が行なわれる。それゆえ、マッチすべきものがないことを
確認するために、プロンプトのように来ることがわかっているパターンを用意する
ことができる。
プロンプトがない場合には、(あなたが手で打つ時に判断しているように)
.B timeout
を用いなければならない。
.IP
パターンは 3 通りに書ける。デフォルトは、Tcl の
.B string match
コマンドの書式である。(このパターンはグロブで参照される C-shell の正規表現に
似ている。)
.B \-gl
フラグは、他のマッチからパターンを保護するのに使う。
"-"で始まるパターンは、この方法で保護すべきである。
("-"で始まる文字列は将来の拡張で、オプションとして使われるかも知れないから)


.IP
例えば、以下の断片はログインの成功を監視する。
.RB ( abort
はスクリプトのどこか他の場所で定義されていると仮定している。
注意すること。)
.nf

.ta \w'      expect 'u +\w'invalid password    'u
    expect {
        busy               {puts busy\\n ; exp_continue}
        failed             abort
        "invalid password" abort
        timeout            abort
        connected
    }

.fi
4番めのパターンにはスペースが含まれているのでクオートが必要である。
アクションとパターンを分離するセパレータでないことを指示する必要がある。
(3番めと4番めの)ように同じアクションを持つリクエストも並べて書く必要が
ある。これは、正規表現パターンを用いることで回避できる(下記参照)。
グロブスタイルパターンについてもっと情報が欲しければ、Tcl のマニュアルを
読むこと。
.IP
正規表現パターンは、Tcl の
.B regexp
("regular expression"の短縮)コマンドで定義される文法に従う。
regexpパターンは、
.BR \-re
フラグで始める。
前の例を、regexp で書き直すと、こうなる。:
.nf

.ta \w'      expect 'u +\w'connected    'u
    expect {
        busy       {puts busy\\n ; exp_continue}
        \-re "failed|invalid password" abort
        timeout    abort
        connected
    }

.fi
どちらのパターンのタイプも、"固定されていない"。どういう意味かというと、
文字列全体にマッチする必要はなくて、文字列のどこでもマッチすれば
良いということである。^ が先頭にマッチする。 $ が末尾にマッチする。
文字列の末尾にマッチさせなければ、spawn されたプロセスからエコーされた
文字列の途中で切り上げてレスポンスを返せることに注意すること。
正しく処理が実行されていても、出力は不自然に見える可能性がある。
それで、文字列の終りの文字を正確に記述できるなら、$ を使うことを勧める。

多くのエディタでは、^ と $ は行頭、行末に正確にマッチする。
しかし、expect は行指向ではないので、(行ではなく)データの始まりと終りに
マッチする。
("EXPECTヒント"内の、バッファリングの消化不良に関する部分を参照のこと)

.B \-ex
フラグは、"正確に(exact)"指示された文字列にマッチする。
* や ^ などの解釈は行なわれない。(ただし、通常の Tcl 展開は行なわれる)。
Exact パターンは常に固定されている。


.IP
.B \-nocase
フラグは、小文字が含まれている場合に大文字に変換してからマッチさせる。
パターンには影響しない。
.IP
出力を読んでいて、2000 バイトを超えてしまったデータは"忘れられる"。
この動作は、
.BR match_max
関数で変更できる。
(極端に大きな値はパターンマッチの性能を低下させることに注意すること。)
.I patlist
に
.BR full_buffer
を指定すると、
.I match_max
バイト以上のデータを受けてパターンマッチしなかったときに、処理が実行される。
.B full_buffer
キーワードの有無に関わらず、忘れられたデータは
expect_out(buffer)
に保存される。

.I patlist
に、キーワード
.BR null
を指定すると、ヌル文字が許可され
(
.B remove_nulls
コマンドを通して)、ヌル文字(ASCII 0)にマッチする。
glob や regexp では 0 バイトにマッチすることができない。

パターン(あるいは、eol, full_buffer)にマッチすると、マッチした部分の文字列か、
その前のマッチしなかった文字列が、変数
.IR expect_out(buffer)
に保存される。

9 個までのマッチした部分文字列は、変数
.I expect_out(1,string)
から
.IR expect_out(9,string)
に保存される。
.B -indices
フラグをパターンの前で指定すると、マッチした部分文字列の
開始位置と終了位置が(
.BR lrange
の引数として使える形で)、変数
.I expect_out(X,start)
と
.I expect_out(X,end)
に保存される。
X は数字で 0 〜 9 まで。
0 はパターン全体がマッチした部分を指示する。
例えば、プロセスが"abcdefgh\\n"を出力し、以下の形:
.nf

    expect "cd"

.fi
で受けると、以下の文を実行したのと同じ結果となる。
.nf

    set expect_out(0,string) cd
    set expect_out(buffer) abcd

.fi
この時、"efgh\\n"は出力バッファに残る。
プロセスが"abbbcabkkkka\\n"を出力し、以下の形:
.nf

    expect \-indices \-re "b(b*).*(k+)"

.fi
で受けると、以下の文を実行したのと同じ結果になる。
.nf

    set expect_out(0,start) 1
    set expect_out(0,end) 10
    set expect_out(0,string) bbbcabkkkk
    set expect_out(1,start) 2
    set expect_out(1,end) 3
    set expect_out(1,string) bb
    set expect_out(2,start) 10
    set expect_out(2,end) 10
    set expect_out(2,string) k
    set expect_out(buffer) abbbcabkkkk

.fi
この時、"a\\n"は出力バッファに残る。
パターン"*" (と -re ".*")は、プロセスからのデータがさらに来ない限り、
出力バッファをフラッシュしない。
.IP
通常、マッチした出力は Expect の内部バッファから、切り捨てらる。
この動作は、
.B \-notransfer
フラグで抑止することができる。このフラグは、スクリプトを試している時に
役に立つ(そして、"-not"と略記しても良い)。

マッチした出力を送ってきたプロセスへの spawn id は、
.IR expect_out(spawn_id)
に保存される。

.B \-timeout
フラグは、この expect コマンドの中の timeout 時刻を timeout 変数でなく
指示された値に設定する。

デフォルトでは、パターンはカレントプロセスからの出力にマッチさせるのだが、
.B \-i
フラグを設定すると、指定された spawn_id リストに対応するプロセス群からの出力に
マッチさせることができる。(次の
.BR \-i
での指定があるまで有効である。)
spawn_id リストは、スペースで区切った spawn_id のリストか、そのような値を持つ
変数への参照でなくてはならない。

例えば、以下の例はカレントプロセスからの"connected"と
$proc2 と言う名前の spawn_id からの"busy","failed","invalid password"
を待ち受ける。
.nf

    expect {
        \-i $proc2 busy {puts busy\\n ; exp_continue}
        \-re "failed|invalid password" abort
        timeout abort
        connected
    }

.fi
大域変数
.I any_spawn_id
の値は、
今の
.B expect
コマンド内で
.B \-i
フラグを指示した spawn_id の全てにマッチさせるために使われる。
.B \-i
フラグをパターンなしで指定すると(すなわち、別の
.BR \-i
が直後に続くと)、
.I any_spawn_id
で指定された、同じ
.B expect
コマンド内の他のパターンに対して、有効になる。

.B \-i
フラグには、グローバル変数の名前を指定することもできる。その場合、
その変数は、spawn id のリストである。変数は変わるたびに読み直される。
こうすることで、コマンドが実行されている間に I/O ソースを変更すること
ができる。この方法で指定される spawn id を"間接(indirect)" spawn id
と呼ぶ。

.B break
や
.B continue
などのアクションは、制御構造(すなわち、
.BR for , proc
)内で通常通りの振舞いをする。

.B exp_continue
コマンドは、
.B expect
ループから抜けるような状況で実行を続けさせる。
.IP
ループを書いたり、expect コマンドを繰り返すことを避ける時に便利である。
以下の例はログインを自動化するコードの断片である。
.B exp_continue
によって、(再びプロンプトを探すための)2 つめの
.B expect
コマンドを書かなくて済んでいる。
.nf

    expect {
        Password: {
            stty -echo
            send_user "password (for $user) on $host: "
            expect_user -re "(.*)\\n"
            send_user "\\n"
            send "$expect_out(1,string)\\r"
            stty echo
            exp_continue
        } incorrect {
            send_user "invalid password or account\\n"
            exit
        } timeout {
            send_user "connection to $host timed out\\n"
            exit
        } eof {
            send_user \\
                "connection to host failed: $expect_out(buffer)"
            exit
        } -re $prompt
    }

.fi
例えば、以下の断片は既に自動化されているユーザーガイドへのやりとりを
補助する。
この場合、端末は raw モードになる。
ユーザーが'+'を押すと変数がインクリメントされる。
"p"が押されると、プロセスへ復帰情報が送られる。
おそらくは同じように"i"が押されると、スクリプトから制御を奪い、
ユーザーからの制御が行なえる。
どの場合も
.B exp_continue
コマンドが、今の
.B expect
に、処理を行なわせた後再びパターンマッチさせている。
.nf

    stty raw \-echo
    expect_after {
        \-i $user_spawn_id
        "p" {send "\\r\\r\\r"; exp_continue}
        "+" {incr foo; exp_continue}
        "i" {interact; exp_continue}
        "quit" exit
    }

.fi
.IP
デフォルトでは、
.B exp_continue
は、タイムアウトタイマーをリセットする。
タイマを再開させるには、
.B exp_continue
コマンドに
.B \-continue_timer
フラグをつける。
.TP
.BI expect_after " [expect_args]"
は、
.B expect_before
と同様の動きをするが、
.B expect
と
.B expect_after
の両方にマッチした場合、
.B expect
のパターンが使用される点が異なる。
より詳しい情報は、
.B expect_before
コマンドの項を参照のこと。
.TP
.BI expect_background " [expect_args]"
は、
.BR expect
と同じ引数をとるが、その場で復帰する。
パターンは新しいデータが届くたびにチェックされる。
パターン
.B timeout
と
.B default
は、
.BR expect_background
には、意味がないし、無視される。
.B expect
と同様に、
.B expect_background
コマンドは
.B expect_before
や
.B expect_after
パターンを使える。

.B expect_background
アクションが、評価される時、同じ spawn id を持つ
バックグラウンドプロセスはブロックされる。
アクションが完了すると、プロセスがアンブロックされる。
バックグラウンドプロセスがブロックされている間は、
(フォアグラウンドの)
.B expect
で、同じ spawn id に接続することができる。
逆に、
.B expect_background
がブロックされていない間は
.B expect
することができない。
特定の spawn id への
.B expect_background
は、同一 spawn id への新しい expect_background を指定すると
削除される。
パターンをつけない
.B expect_background
を指定することで、バックグラウンドでパターンマッチさせること
をやめさせられる。
.TP
.BI expect_before " [expect_args]"
は
.BR expect
と同じ引数をとるが、その場で復帰する。
もっとも最近、同じ spawn id に対して
.B expect_before
で使われたパターン・アクションのペアが、続く
.B expect
コマンドに対して使用される。
パターンがマッチすると、
.B expect
コマンドにマッチした時と同じように動作する。
処理は、その
.B expect
のコンテキストで行なわれる。
.B expect_before
と
.B expect
の両方のパターンにマッチした場合、
.B expect_before
のパターンが使われる。

パターンが指示されなかった場合、spawn id は
どのパターンでもチェックされない。

.B \-i
フラグをさらに指定しない限り、
.B expect_before
パターンは、
.B expect_before
が実行された時に定義されたパターンにマッチする。

\-info フラグは
.B expect_before
から、マッチパターンの現在の状態を復帰させる。
デフォルトでは、現在の spawn id に報告する。オプションの spawn id を
指定することもできる。例えば、
.nf

    expect_before -info -i $proc

.fi
たった一つの spawn id 指定だけが許される。\-indirect フラグで、直接
spawn id を抑止し、間接的な指定から得られるidを指示する。

spawn id を指示する代わりに、"-all"フラグを使って、
全ての spawn id に "-info" の報告をさせることができる。

\-info フラグを使った時の出力結果は、expect_before への引数として
再利用できる。
.TP
.BI expect_tty " [expect_args]"
は、
.B expect
と似た動きをするが、文字列を /dev/tty (すなわち、ユーザーからのキー入力)
から読み込む。
デフォルトでは、cooked mode で読み込まれるので、
行はリターンで終らなければならない。そうしないと
.B expect
が読めない。この動きは、
.B stty
を使って変えられる。
(下の
.B stty
コマンドを参照)
.TP
.BI expect_user " [expect_args]"
は
.B expect
と似た動きをするが、文字列を stdin(すなわち、ユーザーからのキー入力)
から読み込む。
デフォルトでは、cooked mode で読み込まれるので、
行はリターンで終らなければならない。そうしないと
.B expect
が読めない。この動きは、
.B stty
を使って変えられる。
(下の
.B stty
コマンドを参照)
.TP
.B fork
は、新しいプロセスを作る。この新しいプロセスは、現在の
.B Expect
プロセスの正確なコピーである。
成功すると
.B fork
は 新しい(子)プロセスに 0 を返し、親プロセスに 子プロセスのプロセスIDを
返す。
失敗する(スワップ、メモリなどのリソース不足か?)と、
.B fork
は、親プロセスに \-1 を返す。新しい子プロセスは作成されない。
.IP
フォークされたプロセスは、
.B exit
コマンドで ext できる。元のプロセスと同様である。
フォークされたプロセスはログファイルを作っても良い。多くのプロセスで
デバッグもログもできなければ、結果、混乱するだけである。
.IP
pty のインプリメンテーションの中には、複数の読み手と書き手が一瞬でもあれば、
混乱するものがある。それで、プロセスを spawn する前には
.B fork
しておくのが一番安全である。
.TP
.BI interact " [string1 body1] ... [stringn [bodyn]]"
は、現プロセスの制御をユーザーに渡す。結果、
現プロセスに送られたキーストロークと現プロセスの標準出力と標準エラー出力が
復帰する。
.IP
string と body の組が、引数として指示できる。(デフォルトでは、
文字列は現プロセスには送られない)
最後の body がないと、
.B interpreter
コマンドが実行される。
.IP
.B interact
コマンド全体への引数が一行に収まらない場合、"brace"することで各行の終りに
バックスラッシュを入れるのを避けることができる。この場合、Tcl の展開は
ブレースしてあっても起こる。
.IP
例えば、以下のコマンドは続く string body の組と対話する。
: ^Z が押されると
.B Expect
はサスペンドする。
(
.B \-reset
フラグは、端末モードを復旧させる。)
^A が押されると、ユーザーには"you typed a control-A"が返る。
 $ が押されると、ユーザーには日付が返る。
^C が押されると、
.B Expect
は、exit する。
"foo"が入力されると、ユーザーに "bar" が返る。
~~ が押されると、
.B Expect
インタプリタは、対話モードになる。
.nf

.ta \w'    interact 'u +\w'$CTRLZ  'u +\w'{'u
    set CTRLZ \\032
    interact {
        -reset $CTRLZ {exec kill \-STOP [pid]}
        \\001   {send_user "you typed a control\-A\\n";
                send "\\001"
               }
        $      {send_user "The date is [exec date]."}
        \\003   exit
        foo    {send_user "bar"}
        ~~
    }

.fi
.IP
string と body の組で、string が引数として並べられた順に比較される。
部分的にマッチした文字列は、残りが到着するまで送られて来ない。
何文字かさらに打ち込まれて、マッチが可能になると、今のマッチを判断する
ためにだけ使われて他のマッチを始めることはしない。それゆえ、部分的に
マッチしている文字列のマッチが完了するのは遅れることがある。
部分的にはマッチするが最終的にはマッチしない文字列の場合などである。
.IP
デフォルトでは、ワイルドカードを含まないマッチは、exactとなる。
(
.B expect
コマンドがデフォルトでグロブスタイルのパターンを用いるのとは対照的に。)
.B \-ex
フラグは、パターンをプロテクトするのに使える。
.B interact
フラグがそうするように。
パターンが"-"で始まる場合、この方法で保護できる。
("-"で始まる文字列は全て将来のオプションとして予約されている。)

.B \-re
フラグは、正規表現スタイルのパターンとして文字列を解釈する。
この場合、マッチした部分文字列は
.I interact_out
に保存される。
.B expect
が、その出力を変数
.BR expect_out
に保存するのと似たようなものである。
.B \-indices
フラグも同じようにサポートされる。

パターン
.B eof
は、end-of-file にマッチした場合にアクションを実行する。
複数に分かれた
.B eof
パターンには
.B \-output
フラグが続いても良い。その場合、出力が書かれている間に eof が検出されると
アクションを実行する。
.B eof
のデフォルトアクションは"return"である。
それで、
.B interact
は、EOF を見つけると復帰する。

.B timeout
パターンは、(秒で表現された)タイムアウトにマッチし、アクションを実行する。
.B timeout
パターンは、最後に指示されたプロセスに適用される。タイムアウトには
デフォルトの値はない。(expect内で使われる)特殊な変数"timeout"は、
このタイムアウトと関係しない。

例えば、以下の記述は一時間以上タイプしなかったユーザーを自動的にログアウト
させる。その前にシステムから頻繁にメッセージを受けとる:
.nf

    interact -input $user_spawn_id timeout 3600 return -output \\
        $spawn_id 

.fi

パターン
.BR null
と nulls は、(
.B remove_nulls
コマンドを通して)、アスキーの 0 にマッチした場合にアクションを実行する。
glob や regexp で 0 バイトにマッチさせることはできない。

このパターンの前に
.B \-iwrite
フラグをつけると、
変数
.I interact_out(spawn_id)
にパターン(あるいはeof)にマッチした spawn_id が設定される。

.B break
や
.B continue
といったアクションは、制御構造
(すなわち、
.BR for
や
.BR proc
)の中で、通常通りに動く。
しかし、
.B return
は、interact を呼出元に復帰させる。一方、
.B inter_return
は、
.B interact
をその呼びだし元内に復帰させる。例えば、"proc foo" は
.B interact
を呼ぶ。interact が、さらに、
.BR inter_return
を実行すると
.B proc foo
が復帰する。(これは、
.B interact
が、
.B interpreter
を呼んで
.B return
とタイプすると、そのinteractは継続するが、
.B inter_return
すると、その呼出元に復帰してしまうということである。)
.IP
.BR interact
の間 raw モードが使用されるので、全ての文字が現プロセスに渡される。
現プロセスがジョブコントロールシグナルを捕まえなければ、
ストップシグナル(デフォルト^Z)で停止する。再スタートするには、
制御シグナルを送る。("kill \-CONT <pid>"とか打って)。
本当に SIGSTOP をプロセスに送りたいなら、csh を spawn してその上で
プロセスを起動すること。
そうでなくて、
.B Expect
そのものに SIGSTOP を送りたいなら、インタプリタを呼び出して
(普通はエスケープ文字)、その後 ^Z を打つこと。
.IP
string bodyのペアは、インタプリタに入ってコマンドを対話的に実行するのを
避けることを簡単に書くのに使われる。
前の端末モードが、その body を実行する間使用される。
.IP
実行速度を上げるには、デフォルトでアクションが raw モードで動くように
する。
.B \-reset
フラグは、端末の持っているモードをリセットする。そうしなければ、
その前に行なった
.B interact
コマンドの端末モード(cooked モードとか)が保持される。
モードが切り替わった時に、それまで打っていた文字が消えてしまうことが
あるので注意すること。(システムによっては、そういう不幸な仕様をした
端末ドライバが動いている。)
.B \-reset
を使うのは、アクションが cooked モードでしか動かない場合だけである。
.IP
.B \-echo
フラグは、一文字づつパターンにマッチする文字を返す。これは、
ユーザーが打つ文字に部分的にマッチしなければならない場合に有効である。
.IP
パターンはエコーされたがマッチには失敗した場合、文字列は、spawn された
プロセスに送られる。それから、spawn されたプロセスが文字列を表示し、
ユーザーは文字列を二度見る。
.B \-echo
は、ユーザーがパターンを完成させてくれそうもない場合にだけ有効であろう。
例えば、以下は rftp(リカーシブ ftp スクリプト)からの抜粋だが、ユーザーが
~g, ~p, ~l を打つとカレントディレクトリから再帰的(リカーシブ)に get,
put, list する。通常の ftp ではこれらの操作ができない。間違って ~ を
打つか、~ の後を間違えた場合、その文字列を無視するようになっている。
.nf

    interact {
        -echo ~g {getcurdirectory 1}
        -echo ~l {getcurdirectory 0}
        -echo ~p {putcurdirectory}
    }

.fi
.B \-nobuffer
フラグは、文字が読まれる度に、その文字をマッチへ送る。

このフラグは、パターンをエコーバックする時に有効である。
例えば、以下は誰かが(ヘイズモデムを)ダイアルするのを監視するのに
使われる。"atd"が見える度にスクリプトが残りのラインをログする。
.nf

    proc lognumber {} {
        interact -nobuffer -re "(.*)\\r" return
        puts $log "[exec date]: dialed $interact_out(1,string)"
    }

    interact -nobuffer "atd" lognumber

.fi
.IP
.BR interact
の間、前に使った
.B log_user
は無視される。特に、
.B interact
は、その出力を記録される(標準出力に送られる)。
というのは、ユーザーはエコーバックのない状態でキーを打ちたくはない
だろうと考えるからである。
.IP
.B \-o
フラグは、現プロセスの出力に key body ペアの key を結びつける。
こんな場合に便利である。例えば、telnet セッション中に望まない文字を
送ってくるホストを扱う場合である。
.IP
デフォルトでは、
.B interact
は、ユーザーが
.B Expect
プロセス自身の標準入力に書き込み、標準出力を見ていると思っている。
.B \-u
フラグ("user"のu)は
.B interact
に、引数で付けられた名前(spawned id である)のプロセスをユーザーとして
扱う。
.IP
これにより、変なループなしに2つの無関係なプロセスを結合させることが
できる。デバッグする時の助けとして、Expect は常に診断結果を stderr
へ送る。(ある種のログとデバッグ情報は stdout に送られる)。
同じ理由で、
.B interpreter
コマンドは、stdin からデータを読む。
.IP
例えば、以下の断片はログインプロセスを作る。そして、(表示されない)
ユーザーにダイアルし、両方の接続を行なう。
もちろん、loginをどんなプロセスに変えても良い。例えば、シェルなら、ア
カウントとパスワードを与えなくてもユーザーが起動できる。
.nf

    spawn login
    set login $spawn_id
    spawn tip modem
    # dial back out to user
    # connect user to login
    interact \-u $login

.fi
複数のプロセスへの出力を行なうため、
.B \-output
フラグを前につけた各 spawn id のセットがリストされる。
出力 spawn id の組への入力は、
.B \-input
フラグによって決定される。
(
.B \-input
と
.B \-output
フラグは両方とも
.B expect
コマンドの
.B \-i
フラグと同じ書式である。(
.BR interact
内の any_spawn_id は意味がない点を除く。)
以下のフラグと文字列(あるいはパターン)は全て、別の -input フラグが現れるまで
この入力を適用する。
.B \-input
が現れなかった場合、
.B \-output
は "\-input $user_spawn_id \-output"
を行なう。
(
.BR \-input
を持たないパターンも同様である。)
.B \-input
が一つだけ指示されると、$user_spawn_id はその値で置き換わる。
二つめの
.B \-input
が指示されると、$spawn_id が置き換わる。
以降の
.B \-input
フラグも指定できる。

2つの入力プロセスはデフォルトで $spawn_id と $user_spawn_id に出力される。
もし、
.B \-input
フラグが
.B \-output
フラグなしで指定された場合、プロセスからの文字は捨てられる。

.B \-i
フラグは、現在の spawn_id を書き換える。
ただし、
.B \-input
または
.B \-output
フラグが使われていない場合である。\-i フラグは \-o フラグを含む。

間接 spawn id を使って会話しているプロセスを切替えることが可能である。
(間接 spawn id は、expect コマンドの項で説明した)
間接 spawn id は、-i, -u, -input, -output フラグで指定できる。
.TP
.B interpreter " [args]"
は、ユーザーに
.B Expect
と Tcl コマンドのためのプロンプトを表示する。
各コマンドの結果が表示される。
.IP
.B break
や
.B continue
は制御構造(すなわち、
.BR for
.BR proc
)で、通常通りに動く。
しかし、
.B return
は、呼出元への復帰を行なうのに対し、
.B inter_return
は
.B interpreter
を、呼出元を復帰させる。たとえば、
"proc foo" は、
.B interpreter
を呼び、
.BR inter_return
を実行し
.B proc foo
が復帰する。
他のコマンドは
.B interpreter
に新しいコマンドのためのプロンプトを表示し続ける。
.IP
デフォルトでは、プロンプトは 2 つの整数を含んでいる。
最初の数は評価スタックの深さ(つまり、何回 Tcl_Eval が呼ばれたか)
2番めの数は、Tcl ヒストリ識別番号である。プロンプトは
"prompt1"と呼ばれるプロシジャを定義することで設定できる。
このプロシジャの帰り値が次のプロンプトとなる。
記述に開きクオート、括弧、ブレース、ブラケットがあると、次の行には
第 2 プロンプトが現れる(デフォルトは "+> ")。第 2 プロンプトは
"prompt2"と呼ばれるプロシジャを定義することで設定できる。
.IP
.BR interpreter
の間は、呼出元が raw モードであったとしても、cooked モードが使われる。
.IP
stdin が閉じられると、
.B interpreter
は
.B \-eof
フラグが使われていない限り復帰する。
使われている場合は引き続く引数を実行する。
.TP
.BI log_file " [args] [[\-a] file]"
ファイル名が与えられると、
.B log_file
は、(現時点からの)セッションのログをそのファイルに採取する。
引数がなければ、
.B log_file
は記録をやめる。使っていたログファイルはクローズされる。

ファイル名の代わりに、Tcl ファイル識別子を指定すると、
.B \-open
や
.B \-leaveopen
フラグが使える。
.B spawn
コマンドと同様だ(より詳しくは、
.B spawn
を参照)

.B \-a
フラグは、
.B log_user
コマンドによって抑止されたログに出力を強制するものである。

デフォルトでは、
.B log_file
コマンドは古い記録を消して書き直したりせずに
.I 追記
する。
ログオフや複数のログを書く時に都合が良いように。
ファイルを消して書き直す時は
.B \-noappend
フラグを使う。

.B -info
フラグは、最後にログした内容を返す(最後が-infoフラグ付きだったら、
その前の内容)。
.TP
.BI log_user " -info|0|1"
デフォルトでは、send/expect ダイアログは標準出力にロギングされる。
(開いていればログファイルにもロギングされる。)
"log_user 0"とすると、標準出力へのロギングが抑止される。
"log_user 1"とすると、復旧する。ログファイルへの記録については
変更はない。

.B -info
フラグは、最後にログした内容を返す(最後が -info フラグ付きだったら、
その前の内容)。
.TP
.BI match_max " [\-d] [\-i spawn_id] [size]"
は、バッファサイズを(バイト単位で)定義する。このバッファは、
.BR expect
の内部で使われる。
引数
.I size
がないと、現在のサイズを復帰する。
.IP
.B \-d
フラグを指示すると、デフォルトサイズが設定される。(初期状態の
デフォルト値は 2000。)
.B \-i
フラグを指示すると、名前つき spawn id に対してサイズが設定される。
指定しなければ、カレントプロセスに対して設定される。
.TP
.BI overlay " [\-# spawn_id] [\-# spawn_id] [...] program [args]"
は、
.IR "program args"
を現在の
.B Expect
プログラム上で実行する。現在の Expect プログラムは終了する。
ただのハイフンが引数に指定されると、コマンド名の前にハイフンをつけて
ログインシェルとして扱う。
全てのクローズ中の spawn_id は、引数に使われた文字列を待つ。
.IP
Spawn_id は、新しいプログラムに継承させるためのファイル ID に
マップされる。例えば、以下の行はチェスを行ない、chess master
という現プロセスに制御させる。
.nf

    overlay \-0 $spawn_id \-1 $spawn_id \-2 $spawn_id chess

.fi
これは、
"interact \-u"
とするよりも効果的である。しかし、
.B Expect
プロセスが制御していないのでプログラム能力が犠牲となる。
.IP
制御されない端末ができてしまうことに注意すること。それで、
disconnect するか標準入力をリマップするとジョブ制御プログラム
(シェル、ログインなど)が正しく機能しない。
.TP
.BI parity " [\-d] [\-i spawn_id] [value]"
は、spawn idの出力からパリティを保持するか取り除くかを設定する。
.I value
が 0 であれば、パリティは取り除かれる。
それ以外の場合、取り除かれない。
.I value
が指定されない場合、現在の値が復帰する。
.IP
.B \-d
フラグは、パリティのデフォルト値を設定する。(イニシャル時のデフォルト値は
1 である。すなわち、パリティが取り除かれる。)
.B \-i
フラグを指示すると、パリティの値が引数の名前つきの spawn id に対して
設定される。引数がなければ現在のプロセスに対して設定される。
.TP
.BI remove_nulls " [\-d] [\-i spawn_id] [value]"
は、前にパターンマッチしたあるいは
.I expect_out 
か
.IR interact_out
に保存されている spawn されたプロセスの出力からヌルを保持するか取り除くかを
設定する。
.I value
が 1 なら、ヌルは取り除かれる。もし、
.I value
が 0 なら、ヌルは取り除かれる。
.I value
がなければ、現在の値が復帰する。
.IP
.B \-d
フラグは、デフォルト値を設定する。(イニシャルのデフォルト値は、
1 である。それゆえ、ヌルは取り除かれる。)
.B \-i
フラグは、名前つきの spawn id に対して値を設定する。なければ、
現プロセスに対して設定する。

ヌルを取り除くかどうかによらず、
.B Expect
は、ログと標準出力にはヌルが記録される。
.TP
.BI send " [\-flags] string"
.IR string
を現プロセスに送る。
例えば、以下のコマンド:
.nf

    send "hello world\\r"

.fi
は、文字 h e l l o <blank> w o r l d <return>  を現在のプロセスに
送る。
(Tcl は、printf に似たコマンド (
.BR format
と呼ばれる )を持っていて、複雑な文字列を組み立てることができる。)
.IP
文字は直ちに送られる。ただし、入力にラインバッファのあるプログラムでは、
リターンコードが送られるまで文字が読まれない。リターンコードは、
"\\r"と表記する。

.B \-\-
フラグは、続く引数をフラグと解釈せず文字列として解釈される。
全体としてフラグに見えなくても"\-\-"が前についた文字列はフラグとして
扱われてしまう。このフラグは処理されていない文字列がフラグとして
扱われるのを防ぐ。
("-"で始まる文字は全て将来のオプションとして予約されている。)

.B \-i
フラグは、名前つきの spawn_id に文字列を送ることを宣言する。
その spawn_id が
.IR user_spawn_id
であれば、端末はraw モードに入り、文字列中の改行が復帰改行シーケンスに
変換される。それで、外からは 端末が cooked モードとなっているように
見える。
.B \-raw
フラグは、この変換を抑止する。

.BR \-null
フラグは、ヌル文字を送る(0 バイト)。デフォルトでは、ヌル文字を
1つ送る。
.BR \-null
に続く整数はヌル文字をいくつ送るかを指示する。

.B \-break
フラグは、ブレーク状態を作る。spawn id が"spawn -open"で指示した
tty デバイスを参照する場合のみ意味がある。tip などのプロセスを
spawn する場合、tip の都合で ブレーク状態を作るべきである。

.B \-s
フラグは、出力を強制的に"遅く"する。結果、コンピュータが打ち込んでいる
バッファに人間が打ち込んでしまう状況を避けることができる。この出力は
変数"send_slow"の値で制御される。この変数は二つの要素を持つリストである。
最初の要素は、アトミックに送るバイト数である。2 番めの要素はアトミックに送る
間隔(秒)である。例えば、 "set send_slow {10 .001}" は "send \-s" に 
10 文字送る毎に1ミリ秒待つように指示する。

.B \-h
フラグは、人間の実際の入力に似せて send を行なう。(アルゴリズムは、
Weibull distribution に基づいていて、この特定のアプリケーション Expect? に
合わせるための修正が行なわれている。)
この出力は変数"send_human"の値で制御されていて、この変数は 5 つの要素から
なるリストで最初の 2 つの要素は文字間の平均インターバル時間(秒)である。
1 つめがデフォルト値で、2 つめが(通常発生する微妙な待ち時間を表現する)
単語の終りの値である。3 つめの要素は変動率である。
.1 はよく変動する。 1 は妥当な変動率である。 10 だと全然変化しない。
可能な値は 0 から 無限大である。最後の 2 つのパラメタは、それぞれ、
インターバル時間の最小値と最大値である。この 2 つの値は最後に使われて、
最終時刻をクリップする。この 2 値が違うと究極の平均は与えられた平均とは、
全く違ったものになる。

例として、続くコマンドが一定の速度で速く打つタイピストを
エミュレートする:
.nf

    set send_human {.1 .3 1 .05 2}
    send \-h "I'm hungry.  Let's do lunch."

.fi
ハングさせてしまった後は、以下のようにした方が良いだろう。:
.nf

    set send_human {.4 .4 .2 .5 100}
    send \-h "Goodd party lash night!"

.fi
send にエラーや修正を埋め込んであっても、
エラーはシミュレートされない点に注意すること。

ブレークを送るためや、ゆっくりした出力を行なったり、人間が出力したように
見せかけるためにヌル文字を送るフラグは相互排他される。
最後に指定されたものだけが使われる。それ以上は、
.I string
の引数が、ヌル文字あるいはブレークを送るフラグとして指定できる。

最初の
.B send
より前に
.B expect
を置いた方が良い。
.B expect
は、プロセスが始まるのを待てるが、
.B send
は待てない。
特に、最初の
.B send
は、プロセスが走り始める前に完了する。あなたのデータが無視される
危険がある。
最初にプロンプトを表示しないような対話的なプログラムでは、
次のように
.B send
の前にディレイをつけることができる:
.nf

    # どのように破るかのヒントをハッカーに与えてしまわないように、
    # このシステムでは外部のパスワードに対するプロンプトを提供しない。
    # exec が完了するのを 5 秒待て。
    spawn telnet very.secure.gov
    sleep 5
    send password\\r

.fi
.B exp_send
は
.B send
のエイリアスである。あなたが Expectk か、Tk 環境で動く Expect の他の変種を
使っている場合、
.B send
は、全く異なった目的のために使われている。
.B exp_send
が、両環境の間での互換性のために提供されている。
似たようなエイリアスが他の Expect の他の send コマンドのために提供されている。
.TP
.BI send_error " [\-flags] string"
.BR send
と似たようなもので、現プロセスでなく stderr に出力される。
.TP
.BI send_log " [\--] string"
.BR send
と似たようなもので、ログファイルだけに string を送る。(
.BR log_file
を参照。) 引数はログファイルが open されていなければ無視される。
.TP
.BI send_tty " [\-flags] string"
.BR send
と似たようなもので、現プロセスでなく /dev/tty へ出力を送る。
.TP
.BI send_user " [\-flags] string"
.BR send
と似たようなもので、現プロセスでなく標準出力へ出力を送る。
.TP
.BI sleep " seconds"
は、与えられた数字の秒数だけスクリプトがスリープする。
seconds は、10進数だけが許される。
(Expectk を使っている場合、Tkのイベントと)割り込みは、Expectが
スリープしている間も処理される。
.TP
.BI spawn " [args] program [args]"
.IR "program args"
を走らせる新しいプロセスを生成する。その標準入力と標準出力は
Expect に結びつけられる。それで、他の
.B Expect
コマンドで読んだり書いたりできる。
接続は
.B close
によって、あるいは、プロセスそのものがファイル ID の
いずれかをクローズした場合、破壊される。
.IP
プロセスは
.BR spawn
によって始められる。変数
.I spawn_id
には、そのプロセスへの参照を行なう識別子が設定される。
.I spawn_id
によって記述されるプロセスは
.IR "current process"
が考慮される。
.I spawn_id
は、読んでも書いても良く、効果的なジョブ制御を提供する。
.IP
.I user_spawn_id
はユーザーを参照する識別子の入ったグローバル変数である。
例えば、
.I spawn_id
が、この値に設定された場合、
.B expect
は、
.BR expect_user
のような動きをする。

.I
.I error_spawn_id
は、標準エラー出力を参照する識別子の入ったグローバル変数である。
例えば、
.I spawn_id
が、この値に設定された場合、
.B send
は、
.BR send_error
のような動きをする。
.IP
.I tty_spawn_id
は、/dev/tty を参照する識別子の入ったグローバル変数である。
/dev/tty が存在しない(cron, at, バッチスクリプトの中)場合、
.I tty_spawn_id
は定義されない。以下のように確認することができる。:
.nf

    if {[info vars tty_spawn_id]} {
        # /dev/tty exists
    } else {
        # /dev/tty doesn't exist
        # probably in cron, batch, or at script
    }

.fi
.IP
.B spawn
UNIX プロセス ID を復帰する。spawn されたプロセスがない場合、0 が
復帰する。変数
.I spawn_out(slave,name)
は pty スレーブデバイスの名前に設定される。
.IP
デフォルトでは、
.B spawn
はコマンド名と引数をエコーする。
.B \-noecho
フラグで
.B spawn
がこうするのを止められる。
.IP
.B \-console
フラグは、コンソールへの出力を起こし、spawn されたプロセスへの
リダイレクトされる。この機能は未サポートのシステムがある。

内部的に、
.B spawn
は pty を使い、ユーザーの tty と同じように初期化される。これは、かなり
初期化してしまうので全ての設定が (stty(1)によると) "正常(sane)" になる。
変数
.I stty_init
が定義されていると、stty の引数の形式を解釈できるので、より詳細な設定を
行なえる。例えば、
"set stty_init raw"
は、以降 spawn されたプロセスの端末を raw モードで開始する。
.B \-nottycopy
は、ユーザーの tty に基づいた初期化を飛ばす。
.B \-nottyinit
は、"正常な"初期化を飛ばす。
.IP
普通、
.B spawn
は、実行するのにわずかの時間しかかからない。spawn に時間をかけたいので
あれば、おそらく割り込まれた pty に遭遇するだろう。たくさんのテストが
間違ったプロセスに掛かり合うことを避けることができる。
(割り込まれた pty につき、10 秒かかる。)
.B \-d
オプションをつけて Expect を走らせると、
.B Expect
がおかしな状態のたくさんの pty に遭遇しているかどうかが表示される。
これらの pty がつながっているためにプロセスを殺せない場合、リブートするしか
頼れる復旧手段はない。

exec(2)が失敗して
.I program
が spawn に成功しなかった場合
(例えば、
.I program
がなかった場合など)、エラーメッセージが次の
.B interact
か
.B expect
コマンドで復帰する。つまり。
.I program
が、出力としてエラーメッセージを出しているように見せる。
この動作は、
.BR spawn
の実装の自然な帰結である。内部で、spawn がフォークされ、その後、
spawn されたプロセスがオリジナルの
.B Expect
プロセスとその spawn_id で会話を行なう。

.B \-open
フラグは、次の引数を Tcl ファイル識別子として解釈する(つまり、
.BR open
を行なって復帰する。
)
spawn id は、spawn された id として使われる。(ファイル識別子は、
もう使うべきではない。) これにより、
pty を除く、raw デバイス、ファイル、パイプラインを使うことができる。
0 が返ってくるのは、関連するプロセスがなかった時である。
spawn されたプロセスへの接続がクローズされると、Tcl ファイル識別子も
クローズされる。
.B \-leaveopen
フラグは、
.B \-open
と似た動きをするが、
spawn id をクローズした後もファイル識別子を開いたままにする点が違う。

.B \-pty
フラグは、
pty をオープンするがプロセスをspawnしない。0 が復帰するのは、
関連するプロセスがない場合である。spawn_id は、通常通り設定される。

変数
.I spawn_out(slave,fd)
には、pty スレーブとつながっているファイル識別子が設定される。
"close -slave" で close できる。

.B \-ignore
フラグは、spawn されたプロセス中で無視されるシグナルの名前を指示する。
なければ、シグナルはデフォルトの振舞いをする。シグナルの名前は
.B trap
コマンドで使う名前と同じである。各シグナルを分離するのにフラグが
必要な点を除いては。
.TP
.BI strace " level"
は、以降の命令を実行する前に表示を行なう。
(Tcl の trace は、変数のトレースを行なう。)
.I level
は、トレースへの呼び出しスタックの深さを示す。
例えば、
以下のコマンドは
.B Expect
最初の 4 レベルの呼び出しをトレースする。
それ以上の深さはトレースしない。
.nf

    expect \-c "strace 4" script.exp

.fi

.B -info
フラグを指定すると、strace は最後の info でない指定の内容を復帰する。
.TP
.BI stty " args"
は端末モードを変更する。外部の stty コマンドと似たようなものである。

デフォルトでは、制御している端末がアクセスされる。他の端末は、
"< /dev/tty..." を追加することでアクセスできる。(引数を一つの引数に
まとめるべきではない。)

ステータス要求はコマンドの結果としてステータスを復帰する。
ステータスが要求されずに制御している端末にアクセスする場合、直前の raw と
echo の状態を返す。

例えば、引数
.B raw
か
.B \-cooked
は、端末を raw モードに設定する。
引数
.B \-raw
か
.B cooked
は、端末を cooked モードに設定する。
引数
.B echo
か
.B \-echo
は、端末をそれぞれ echo あるいは noecho モードに設定する。
.IP
以下の例は、一時的なエコー禁止をどうやっておこなうかを示す。
これは、他の自動スクリプトで、その中にパスワードが埋め込まれるのを
防ぐことに使われる。(もっと議論したければ、下の EXPECT ヒントに
ある。)
.nf

    stty \-echo
    send_user "Password: "
    expect_user -re "(.*)\\n"
    set password $expect_out(1,string)
    stty echo

.fi
.TP
.BI system " args"
は、
.I args
を、sh(1)に入力する。端末からコマンドを叩くのとちょうど同じである。
.B Expect
は、シェルが終るのを待つ。sh からの復帰値は、
.B exec
がその復帰値を扱うのと同じに扱われる。
.IP
.B exec
が、スクリプトに標準入出力をリダイレクトするのと対照的に、
対照的に
.B system
は、リダイレクションを行なわない。(他に文字列そのものでリダイレクトを
指示しない限り。) それで、/dev/tty と直接話さなければならないプログラムを
使うことができる。同じ理由で、
.B system
の結果は、ログに記録されない。
.TP
.BI timestamp " [args]"
は、タイムスタンプを復帰する。
引数がない場合、復帰するまでの秒数が返る。

.B \-format
フラグは、文字列が続くが、その文字列に
POSIX の strftime のルールに従って置換がかかる。
例えば、 %a は曜日(すなわち、Sat)とか。他は以下の通りである。:
.nf
    %a      略記された曜日の名前
    %A      略されない曜日の名前
    %b      略記された月の名前
    %B      略されない月の名前
    %c      次の形式で書かれた時刻: Wed Oct  6 11:45:56 1993
    %d      日 (01-31)
    %H      時 (00-23)
    %I      時 (01-12)
    %j      日 (001-366)
    %m      月 (01-12)
    %M      分 (00-59)
    %p      am または pm
    %S      秒 (00-61)
    %u      日 (1-7, 月曜日が週の最初の日)
    %U      週 (00-53, 最初の日曜日が第1週の最初の日)
    %V      週 (01-53, ISO 8601 スタイル)
    %w      日 (0-6)
    %W      週 (00-53, 最初の月曜日が第1週の最初の日)
    %x      date-time as in: Wed Oct  6 1993
    %X      time as in: 23:59:59
    %y      year (00-99)
    %Y      year as in: 1993
    %Z      timezone (or nothing if not determinable)
    %%      a bare percent sign

.fi
この他の % 指定は定義されていない。他の文字は変更されない。
C ロカールだけがサポートされる。

.B \-seconds
フラグは、
タイムスタンプを秒で表す。

.B \-gmt
GMT タイムゾーンで出力する。デフォルトはローカルタイムゾーンである。
.TP
.BI trap " [[command] signals]"
を実行すると、以降指定された signal を受けとると指定された
.I command
を実行する。
このコマンドは、グローバルスコープで実行される。
もし、
.I command
が指定されなければ、シグナルアクションが復帰する。
.I command
が、文字列 SIG_IGN であれば、シグナルが無視される。
.I command
が、文字列 SIG_DFL であれば、シグナルはデフォルトの動きをする。
.I signals
は、シグナルが１つでも複数のシグナルのリストでも良い。シグナルは、
数字とsignal(3)に記述されている文字列のどちらで指定しても良い。
プレフィクスの"SIG"は、省略しても良い。

引数がなければ(または、引数 \-number であれば)、
.B trap
は、trapコマンドで横取りされているシグナル番号を復帰する。

.B \-code
フラグはコマンドコードを返す。Tcl がコマンドを動かし始めた時に
帰そうとしたコードである。

.B \-interp
フラグは、trap が宣言された時でなくコマンドが開始された時にインタプリタに
コマンドを評価させる。

.B \-name
フラグは、
.B trap
コマンドに trap のかかっているシグナル名を帰す。

.B \-max
フラグは、
.B trap
コマンドに設定できる最も大きなシグナル番号を帰す。

例えば、"trap {send_user "Ouch!"} SIGINT" は、
ユーザーが ^C を押す度に "Ouch!" を表示する。

デフォルトでは、SIGINT(通常 ^C を押すと発生する)や
SIGTERM は、Expect を exit させてしまう。これは、Expect が起動時に
実行する以下の trap によって起こっている。
.nf

    trap exit {SIGINT SIGTERM}

.fi
-Dフラグを使ってデバッガを起動するなら、SIGINT が再定義されてから対話型
デバッガが起動される。これは以下の trap によって起こる。
.nf

    trap {exp_debug 1} SIGINT

.fi
デバッガのトラップは、環境変数 EXPECT_DEBUG_INIT を設定して、新しく
trap を起動することで変更できる。

もちろん、スクリプトにtrapコマンドを足すだけで例のトラップは両方とも
上書きできる。特に、自作の "trap exit SIGINT" があるなら、これは
デバッガのトラップを上書きしてしまう。ユーザーにデバッガを全く
触らせないようにするのに、便利である。

SIGINT のトラップを独自に定義したいけれど、デバッガにも同時に割り込んで
もらいたいのであれば、こう書く。:
.nf

    if ![exp_debug] {trap mystuff SIGINT}

.fi
代わりに、別のシグナルを使ってデバッガに割り込みをかけることができる。

.B trap
は、SIGALRM のアクションを上書きしない。
.BR Expect
が内部で使用しない。
disconnect コマンドは、SIGALRMを SIG_IGN (ignore)に設定する。
後から発行される spawn コマンドを実行している間、SIGALRM は
ディスエーブル中であれば再度イネーブルにできる。

もっと情報が欲しい場合、signal(3) を参照すること。
.TP
.BI wait " [args]"
は、spawn されたプロセス(あるいは、名前つきのプロセスがなければ現在のプロセス)
が終了するのを待つ。
.IP
.B wait
は、通常 4 つの整数のリストを帰す。
最初の整数は、終了を待ち構えているプロセスの pid である。
2 つめの整数は、関連する spawn id である。
3 つめの整数は、オペレーティングシステムエラーがあれば -1、
そうでなければ、0 である。
3 つめの整数が 0 であれば、4 つめの整数はspawnされたプロセスからのリターン
コードである。3 つめの整数が -1 であれば、4 つめの整数はオペレーティングシステム
によって設定された errno の値である。グローバル変数 errorCode も設定される。

追加の要素が
.BR wait
の復帰値に加わっても構わない。オプションの5つめの要素は、情報クラスの
識別子である。今のところ、この要素の唯一可能な値は CHILDKILLED で、
その場合、次の二つの値が C スタイルのシグナル名と短い文書による記述である。
.IP
.B \-i
フラグによって、wait を行なう名前付き spawn_id(プロセス ID ではなく)を
指定する。SIGCHLD ハンドラの内部では、spawn ID -1 を指定することで、
spawn されたプロセスのいずれかを wait できる。

.B \-nowait
フラグを指定すると、wait が成功の復帰値で即時復帰する。
(あとで)そのプロセスが exit すると、自動的に後始末が行なわれ、明示的に
wait する必要がない。

.B wait
コマンドは、引数に "-i -1" を指定することによって、
fork したプロセスを待つためにも使われる。
spawn したプロセスに用いられる場合と異なり、
このコマンドはいつでも実行できる。
どのプロセスを待つかを制御することは出来ないが、
返り値はプロセス ID としてチェックできる。

.SH ライブラリ
Expect は、スクリプトのための二つのビルトインライブラリを自動的に理解する。
それらは変数 exp_library と変数 exp_exec_library に設定されたディレクトリ名と
して定義される。これらのディレクトリには、他のスクリプトによって使える
ユーティリティファイルが入っている。

exp_library には、アーキテクチャに依存しないファイルが格納される。
exp_exec_library には、アーキテクチャに依存するファイルが格納される。
あなたのシステムによっては、両方のディレクトリが空という場合もあり得る。
ファイル $exp_exec_library/cat-buffers の存在は、あなたのシステムの
/bin/cat がデフォルトでバッファリングされているかどうかに左右される。

.SH 整形印刷
.B Expect
スクリプトをきれいに印刷するための vgrind の定義がある。
.B Expect
ディストリビューションと一緒に配布されている vgrind 定義が正しく
インストールされていると仮定して、こうすれば使える。
.nf

    vgrind \-lexpect file

.fi

.SH 例
マニュアルページによる記述では、あらゆるものをどう組み合わせるのかと
いうことが明白ではない。私としては、
.B Expect
ディストリビューションの
example ディレクトリにある例を読んで試してみて欲しいと思う。
いくつかは本物のプログラムである。それ以外は特定のテクニックの単純な解説、
あと、もちろん、単なるクイックハックが少しある。
INSTALL ファイルにはこれらのプログラムの簡単な梗概が書かれている。
.PP
.B Expect
の論文も役に立つ(関連項目参照)。いくつかは、初期バージョンの Expect の
文法を使っているが、それとともにある根本的な考えは、なお有効であり、
このマニュアルページより詳細に書かれている。

.SH 警告
拡張は Expect のコマンド名と衝突するかもしれない。例えば、
.B send
は、Tk では全く別の目的で定義されている。
そういう理由で、ほとんどの
.B Expect
コマンドは、"exp_XXXX" という 別の記法(エイリアス)もサポートする。
"exp", "inter", "spawn", "timeout" で始まるコマンドと変数は、
エイリアスを持たない。
この環境間の互換性が必要であれば、拡張されたコマンド名を用いること。

.B Expect
は、かなり自由なスコープを持っている。特に、
.B Expect
プログラムで指定したコマンドにより読み込ませる変数は、そのローカルスコープ
内でまず探索され、見つからなければ、グローバルスコープで探索される。
例えば、こうすることで
.BR expect
を使う全てのプロシジャに "global timeout" を書く必要が
なくなる。
逆に、プロシジャ内に書かれた変数は全てローカルスコープ内に設定される。
("global"コマンドを指定しない限りは)。この動作が引き起こすもっとも共通した
問題は、spawn がプロシジャ内で実行された時である。プロシジャの外では、
.I spawn_id
はスコープのため、もはや存在しないので spawn されたプロセスは単純には
アクセス不能となる。そのようなプロセスには、"global spawn_id"を
付け加えねばならない。

multi-spawn 機能が使えない(つまり、あなたのシステムが
select (BSD *.*), poll (SVR>2),または、それと等価なもの のいずれも
サポートしていない)場合、
.B Expect
は、同時に 1 プロセスしか制御できない。
この場合、
.IR spawn_id
を無理に設定したり、spawn されたプロセスが走っている間に exec を使って
プロセスを実行したりしてはならない。さらに、複数のプロセス(片方が
ユーザーでも)から同時に
.B expect
することもできない。

端末制御パラメタは、スクリプトに大きな影響を与える。例えば、
スクリプトがエコーを探すように書かれていれば、エコーをオフにすると
動作がおかしくなる。この理由で、Expect はデフォルトで 正気の
端末パラメタを設定する。不幸なことに、この設定が他のプログラムではまずい
場合がある。例えば、emacs シェルは"通常の"マッピングを変更しようとする。
: newlinesは、carriage-return newlines に変換されず newlines にマップされる。
そして、エコーは行なわれない。こうマップされることで、emacs は入力行を
編集できる。残念ながら、Expect はこのマッピングを検出できない。

Expect が端末パラメタのデフォルト設定を上書きしないように指定することが
できるが、そういった環境で動かすスクリプトを書くときは細心の注意が
必要である。emacs の場合、エコーや改行コードのマッピングを回避しなければ
ならない。

(
.B expect
とその変種、および、
.BR interact
といった)1 つのリストにブレースされた引数を受けとるコマンドは、
リストが引数をどれだけ持っているのかを判断するのに、発見的手法を用いる。
その発見的手法はが失敗する唯一の場合は、引数の一つに複数の\\nが埋め込まれ、
その間にホワイトスペースがない場合である。これは十分検出不能な状態だが、
引数"\-nobrace" で、強制的に一つの引数として扱うことができる。
自動的に生成された Expect コード中で使われるかもしれない。
同様に、-brace は複数のパターン/アクションをひとつの引数として扱うことを
強制する。

.SH バグ
プログラムに "sex" ("Smart EXec" か "Send-EXpect" の略) という名前を
つけるのは実に魅力的だったのだが、センスの良い方(あるいは、
単にピューリタニズム)が優先された。

シェルが spawn されるとttyにアクセスできないと文句をいって、しかし、動作はする
というシステムがある。これは、このシステムがtty制御を得るための機構を
持っているが
.B Expect
はそれを知らないという意味である。どういう仕組みか調べて、その情報を私に
知らせてほしい。

Ultrix 4.1 (少なくとも最新バージョンのあたり) では、
1000000 を超えるタイムアウトを 0 とみなしてしまう。

Digital UNIX 4.0A (おそらく他のバージョンも)は SIGCHLD ハンドラを
定義すると、pty の割り付けを拒否する。詳細は grantpt ページを参照のこと。

IRIX 6.0 は、pty へのアクセス制御を正確に扱えない。それで、
Expect は、pty がアロケートできない場合は、他の人が前に使った pty の
アロケートを試みる。
IRIX 6.1 にアップグレードすること。

telnet (SunOS 4.1.2 でのみ確認)は、TERM が設定されてないと
ハングする。この問題は cron や at や CGI スクリプトで使う時に問題だ
(設定しないので)。それで、
明示的に指定しなくてはならない - 本当のタイプは通常関係ない。
何かに設定してないと駄目なのだ! 以下の記述はおそらくほとんどの場合を
満足させるだろう。
.nf

    set env(TERM) vt100

.fi

tipt (BSDI BSD/OS 3.1 i386 でのみ確認)は、SHELL と HOME が設定されてないと
ハングする。この問題は cron や at や CGI スクリプトで使う時に問題だ
(設定しないので)。それで、
明示的に指定しなくてはならない - 本当のタイプは通常関係ない。
何かに設定してないと駄目なのだ! 以下の記述はおそらくほとんどの場合を
満足させるだろう。
.nf

    set env(SHELL) /bin/sh
    set env(HOME) /usr/local/bin

.fi


pty のインプリメントの中には、プロセスがファイル記述子をクローズした後、
読んでない出力を 10 から 15 秒後(この値はインプリメントに依存)に投げてくる
ものがある。それゆえ、
.nf

    spawn date
    sleep 20
    expect

.fi
のような
.B Expect
プログラムは失敗する。失敗しないように非対話的なプログラムでは
.BR spawn
せずに
.B exec
すること。こういう状況は考えられるが、実際には私はまだその状態に
陥ったことがない。つまり、この原因で対話プログラムの最後の出力を
取りこぼすという状態になったことがない。

一方、Cray UNICOS の pty は読み込んでいない出力をファイルディスクリプタを
プロセスが閉じるとすぐに投げてくる。私は Cray にこの動きについて報告し、
回避するための修正を行なった。

プロンプトと応答の間にディレイが必要な場合がある。tty インターフェースが
UART の設定を変えたり、スタート/ストップビットを探してボーレートを合わせて
いる時などである。通常、ここで必要とされているものは 1 秒か 2 秒の待ち合わせである。
もっとしっかりしたやり方はハードウェアが入力を受ける準備ができるまで繰り返す
ことである。以下の例は、両方の戦略を採用している。:
.nf

    send "speed 9600\\r";
    sleep 1
    expect {
        timeout {send "\\r"; exp_continue}
        $prompt
    }

.fi

\-code をトラップするのは Tcl のイベントループに依存しているコマンド
(sleep など)では動かない。
問題は、イベントループの中では Tcl は非同期イベントハンドラからの
返り値を捨てているからである。
回避方法としては、トラップコードでフラグをセットし、
コマンド(sleep など)の直後でフラグをチェックすることである。

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

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

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

    expect -re $prompt

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

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

X* の形のパターンを使うのであれば、* はXから最後に受けとる何かまでの
全てにマッチする。これは一見直観的だが、"最後に受けとる何か"が
コンピュータの速度とカーネルとデバイスドライバによるI/O処理によって
変わってしまうので混乱するだろう。
.PP
特に、人間はプログラムの出力が巨大なひとまとまりとしてやってくると思いがち
だが、実際には、ほとんどのプログラムは一行を一度に送る。
こう仮定すると、直前の段落のパターンにあった * は、行の終りにしか
マッチしないかも知れない。たとえ、もっと入力があると思われる場合でも
出力を全て受けとった時点でしかマッチを行なわないのである。
.PP
.B expect
は、指定したパターンが教えてくれない限り、出力がさらにやってくるのか
どうかわからない。
.PP
行指向のバッファリングを行なっている場合ですら、賢いやり方とはいえない。
プログラムはバッファリングのタイプをめったに保証しないだけでなく、その際に
消化不良を起こして出力行を中断し、行末をバッファ中のランダムな位置に
置いてしまう。
それで、パターンを書く時には、プロンプトの最後の何文字かを入れておいた方が
賢いやり方といえるのである。

プログラムの最後の出力にあるパターンを待ち、実際には何がしか他のものが
発行されている場合には
.B timeout
キーワードで判定することができない。理由は、
.B expect
が、タイムアウトしない \- そのかわりに
.B eof
を見つけられる \-
からである。
代わりになるものを使うこと。もっと良いのは、両方使うことだろう。
行が回り込んだ場合でも、行そのものを編集するべきではない。

tty ドライバによって出力される時に
newline は、普通 carriage return, linefeed の組に変換される。
それで、2 ラインにマッチするには、例えば、printf("foo\\nbar") に
マッチさせるには、"foo\\r\\nbar" というパターンを使うことになる。
.PP
似たような変換は、ユーザーから
.BR expect_user
を通して入力を読み込む時にも起こる。この場合、ユーザーがリターンを
押すと、それは newline に変換される。その後、
.B Expect
が端末モードを raw モード(telnet のような)を設定すると、問題が発生する
可能性がある。プログラムが本当のリターンを待ってしまうからである。(プログラムの
中には、newline をリターンに変えても大丈夫なものもあるが、ほとんどはだめである。)
残念ながら、プログラムが端末を raw モードにすることを検出する方法がない。
.PP
手で newline をリターンに変えるのではなく、"stty raw"を使うのが解決策である。
stty raw は、変換を停止する。しかし、こうすると cooked モードの行編集機能が
使えなくなるということに注意すること。
.PP
.B interact
は、端末を raw モードに設定するので、この問題は発生しない。

.B Expect
スクリプトの中でパスワード(や他の機密情報)を保存すると便利なことは
よくある。だれかのアクセスを受けるとその影響を受けてしまうコンピュータで
そういうことをするのは勧められない。それで、パスワードのプロンプトを
スクリプトから出すのが、文字通りパスワードを埋め込むよりは、良い考えと
いえる。とはいうものの、そういった埋め込みをするしかない場合もある。
.PP
不幸なことに、UNIX のファイルシステムは「実行可能で読めない」スクリプトを
作る直接の方法がない。setgid シェルスクリプトをサポートしたシステムでは、
次のようにすることで間接的にシミュレートできる。
.PP
,
.B Expect
スクリプト(機密情報の入った)を普通に作る。
そのパーミッションを 750 (\-rwxr\-x\-\-\-) に設定し、trusted group 
つまり、読んでも良いグループ の所有とする。必要なら、この目的のための
新しいグループをつくること。次に、/bin/sh スクリプトを パーミッション
 2751 (\-rwxr\-s\-\-x) で、同じグループの所有で作成する。
.PP
こうすると、シェルスクリプトはだれからも実行でき(かつ、読め)る。
実行すると、それは
.B Expect
スクリプトを実行する。

.SH 関連項目

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

.SH 著者

Don Libes, National Institute of Standards and Technology

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

.PP
HISTORY ファイルに
.B expect
の進化の大部分が記述されている。このファイルは面白く読めて、かつ、
あなたのこのソフトウェアへの洞察をより深くするだろう。このファイルに
書かれている、私にバグフィックスを送ってくれた人たちや、他の援助を
してくれた人たちに感謝する。
.PP
.B Expect
の設計と実装は、部分的にアメリカ政府からその対価をもらっているので、
パブリックドメインである。しかし、このプログラムとドキュメントあるいは
その一部が使われたなら、著者と NIST への謝辞を述べてもらいたい。