撥號文件描述各種各樣被使用的撥號程序的方法。傳統地, UUCP 更多地談到撥號程序而非調制
解調器,因為在早些次數中，通常的實踐是，擁有一個(昂貴的)自動撥號的設備提供調制解調器
整個銀行的服務。今天,大多數調制解調器內部建有撥號支持,因此這種區別有點模糊。
但是，不同的撥號程序或調制解調器可能要求不同的配置。你能在撥號文件中描述他們每一個。
撥號中的入口以給出撥號程序名字的撥號程序命令開始。
與此比較的最重要的入口是調制解調器聊天,由聊天命令指定了。類似登錄聊天，它由 uucico 發
送到撥號程序的一個順序行組成，並且它期望作為回報的反應。它通常被用來重新設置調制解調器
到一些知道的狀態，並且撥數字。下個例子樣品撥號程序入口為一個Hayes兼容的調制解調器顯示
出一個典型的調制解調器聊天：
調制解調器聊天以空的期望字符串開始。因此 uucico 將馬上發送第一個命令( ATZ )。 ATZ 是重
新設置調制解調器的 Hayes 命令。然它等待，直到調制解調器發送好了，並且發送關掉本地回響
的下一個命令,等等。在調制解調器再次返回OK以， uucico 發送撥號命令( ATDT )。在這個字符
串中的逃跑順序 T 被拿自系統入口 sys 文件中的電話號碼代替。然 uucico 等待調制解調器返
回字符串CONNECT,它發出遠程調制解調器的一個連接成功地被建立了的信號。
通常,調制解調器不能與遠程系統聯接,例如，如果另外的系統正與另外的某人在談話並且線路正忙。
在這種情況中，調制解調器將返回一些顯示原因的錯誤消息。調制解調器聊天不能檢測這樣的消息;
uucico 將繼續等待期望的字符，直到它超時為止。因此 UUCP 記錄文件將僅僅顯示出一行“在聊天
手跡中超時了”，而不是真實的原因”。
然而, Taylor UUCP 允許你告訴 uucico 這些出現在上面的使用聊天失敗命令的錯誤信息。當執行
調制解調器聊天時， uucico 檢測一個聊天失敗字符串時，它放棄呼叫，並且在 UUCP 記錄文件中
記載錯誤消息。
在上面被顯示出的例子中的最命令告訴 UUCP 在開始調制解調器聊天前套牢 DTR 行。當在DTR行上
檢測一個變化時，大多數調制解調器能被設置在鉤上，並且進入命令模式。
(http://www.fanqiang.com)
進入【UNIX論壇】
|
![[ 永遠的UNIX::UNIX技術資料的寶庫 ]](/images/title.gif)