問題タブ [pty]

こんにちは、この投稿によると、疑似端末 (pty) を介してコマンドにunbuffer接続します。これにより、システムは対話型プロセスとして扱われるため、stdout バッファリングは使用されません。

この機能を Windows で使用したいと考えています。unbufferWindows の program に相当するものを教えてください。ありがとう。

ssh を使用してリモート サーバーに接続し、ユーザーにシェル ターミナルを提供するプログラムを作成しています。

私は JSch と sshj を試しました。どちらも適切に接続できますが、シェル チャネルの入出力ストリームを System.in と System.out に接続するだけで、ファンキーな出力が生成されます。理由はわかっています.JSchとsshjの両方のドキュメントには、ターミナルエミュレーションが組み込まれていないため、入出力が見にくいと書かれています。(sshj はこの実装を「初歩的な PTY」と呼んでいます)

また、JTerm、DragonConsole、Terminator などのターミナル エミュレーターも選択できます。

私の目標は、ターミナル エミュレーター ウィンドウを起動し、シェル チャネルからの入出力ストリームをエミュレーターに接続するのと同様のことを行うことです。

ジャンク文字を取り除くために、シェルチャネルへの/からの入出力を自分で処理する方法を提案するなどの代替手段も高く評価されます-それが主な問題です。

編集：これがsshjの「初歩的なPTY」です

そして、これがJSchバージョンです

Cでopenptyを使用してptyを作成し、マスター/親とスレーブ/子の間で共有しています。子はfork/execを実行し、ファイル記述子を他のプログラムに渡すことができます。子供にコマンドを注入したいのですが、すぐに渡すと迷子になります。親プロセスから、誰かがstdinからの入力をブロックしていることをどのように知ることができますか？私はたまたまSUSE10に取り組んでいますが、ディストリビューションに依存しないソリューションを好みます。

編集：この質問への答えはまだ私には興味深いですが、問題に関連していない可能性があります。後で説明します。

コードの簡略化されたバージョンは、スクリプトのソースコードを使用し（ヘッダーの一部を修正する必要がある場合があります）、行を追加することです。

ビッグの前に

主に。

スクリプトからcshを実行していましたが、スクリプトコマンドがガベージをダンプしていることに気付きました（viで表示）。

親のstdinに。代わりにbashシェルを実行すると、何もダンプされず、プログラムはコマンドを正常に挿入します。

質問に対する答えについてはまだ興味がありますが、他に何かが起こっているため、明らかに私の問題とは関係がありません。ptyが読み取られているかどうかを確認する方法を誰かが知っている場合は、遠慮なく答えてください。

Resource Temporically Unavailable（11）の読み取り/書き込みエラーが発生する疑似端末スレーブがあります。私はこの問題を解決することができませんでしたが、一週間前まで私は何もptyを知りませんでした。だから、私は明らかな何かを見逃しているかもしれません。

read()私が読んだことから、これは非ブロッキングptyを呼び出すことによって引き起こされる可能性があります。F_GETFLただし、スレーブptyの後でチェックするopen()と、値はそれがブロッキングファイル記述子であることを示しています。

の出力はF_GETFL、O_NONBLOCKフラグが無効になっていて、O_RDWRフラグが有効になっていることを示しています。

いつ準備ができているかを判断するためにslavefdを使用して、非ブロッキングファイルとして扱うことも試みました。select()しかし、それは毎回タイムアウトするだけです。

では、がブロッキングに設定されている場合、なぜread()errnoをResource Temporically Unavailableに設定するのですか？slavefdのフラグはF_GETFL正しいですか？この問題の原因を絞り込むために他に何を試みることができますか？

更新:(詳細）

まだわかりませんが、ptyスレーブデバイスノードがpppdによって何らかの形でロックされていると思います。私はあなたがptyスレーブにエコーすることができると言われました、それはpppdがそれを使用しているときを除いて本当のようです。

アップデート2:(コードを追加）

このアップデートは、スレーブデバイスを開く方法を示しています。このアプリケーションをデバッグに使用しているので、直接使用してargv[1]います。

問題が解決しました：

読み取り/書き込みを試みていたスレーブノードがpppdによって変更されていました。pppdがtty/ptyデバイスを制御すると、回線の規律がからN_TTYに変更されN_PPPます。これは、スレーブノードに対してopen()、read()またはwrite()スレーブノードに対して、TTYドライバーの代わりにPPP中間ドライバーが使用されていることを意味します。つまり、aread()とwrite()はまったく異なる関数に要約されます。N_PPPドライバーを見ると、次のことがわかりました。これは、なぜEAGAINが返送されたのかという私の質問に答えます。

私は Linux デーモンを作成しており、telnet 経由でそのパラメーターを構成する機能を実装したいと考えています。履歴とコンプリーターを備えた gnu readline ライブラリを使用して記述された cli インターフェイス コードがあり、そのインターフェイス コードをデーモンに使用したいと考えています。

stdin/stdout をソケットにリダイレクトし、rl_instream/rl_outstream をソケットにリダイレクトし、マスター/スレーブ pty に読み書きしようとしましたが、成功しませんでした。

同様の質問が回答なしでここで尋ねられました。

this questionも読んでください。ただし、子プロセスはありません。

私の質問は次のとおりです。

1. 単一プロセス内で pty 機能を使用するにはどうすればよいですか?
2. プロセスが 1 つしかない場合、マスターとスレーブの pty を使用する必要がありますか?

コード例 (pty デバイスでの操作なし)、期待される結果 - readline は正常に動作します

どうもありがとう。

Linux でシリアル ポートへのアクセスを多重化しようとしています。シリアル ポートが 1 つしかない組み込みシステムを使用していますが、複数のプロセスが通信できると便利です。

一般的な使用例は次のとおりです。

• テストを実行する 1 つのメイン プログラム (コマンドの送信と出力の受信)。
• すべてのシリアル ポート アクティビティを別のログに記録します。
• テスト中に何らかのエラーが発生した後、追加のコマンドを送信したり、事後分析を実行したりするためにユーザー端末が開きます。

まず、n 個の疑似端末ペア (およびシリアル ポート) を開く単純な python スクリプトを作成し、poll ステートメントを使用して適切な場所に入出力を送信します。

このアプローチは、すべての pty が接続されている場合に非常にうまく機能します。接続されていない pty がある場合、最終的にそのバッファーがいっぱいになり、書き込み時にブロックされます。どのスレーブが接続されているか、または何らかのオンデマンドの pty を開くかを知る必要があるようです。

私はこの質問で巧妙なトリックを見つけました。その上で、男はシリアルポート部分からの読み取りだけを行う必要があるため、スクリプトを調整しました:

これは機能しますが、リーダーのポーリングに POLLHUP イベントが殺到するため、CPU を 100% 使用します。

疑似端末の代わりに TCP ソケットを使用すれば、必要なものが得られると思います。欠点は、ソケットを使用するために、端末で既に動作している他のすべてのスクリプトを変更する必要があることです (socat を使用できることはわかっていますが、もっと単純なものが必要なだけです)。その上、ネットワークのオーバーヘッドがすべてあります...

それで、何かアイデアはありますか？

セットアップが簡単である限り、他のツールを使用してもかまいません。他の言語を使用することも気にしません。Python が一番好きです。

私がやろうとしていること

私の Cocoa アプリでは、一連のコマンドライン プログラムを実行する必要があります。これらのほとんどは非対話型であるため、いくつかのコマンド ライン引数を指定して起動すると、目的の処理を実行し、何かを出力して終了します。プログラムの 1 つは対話型であるため、テキストとプロンプトを stdout に出力し、stdin での入力を期待します。これは、quit コマンドを送信するまで続きます。

機能するもの

大量のデータを stdout にダンプしてから終了するだけの非対話型プログラムは、比較的単純です。

• NSPipestdout/stdin/stderr の を作成します
• NSTaskそれらのパイプで起動します

次に、どちらか

• NSFileHandleパイプのもう一方の端がストリームの最後まですべてのデータを読み取り、タスクの終了時に一度に処理するように取得します

また

• 出力パイプのもう一方の端-fileDescriptorから を取得します。NSFileHandle
• ノンブロッキング モードを使用するようにファイル記述子を設定する
• を使用して、これらのファイル記述子のそれぞれで GCD ディスパッチ ソースを作成します。dispatch_source_create(DISPATCH_SOURCE_TYPE_READ, ...
• ディスパッチソースを再開し、それがスローするデータを使用して処理しますread()
• タスクが終了し、パイプ ファイル記述子が EOF を報告するまで続行します ( read()0 バイトの読み取りが報告されます)。

うまくいかないこと

どちらのアプローチも、インタラクティブ ツールでは完全に機能しません。明らかに、プログラムが終了するまで待ちきれません。プログラムはコマンド プロンプトで待機していて、指示しない限り終了しないからです。一方、NSPipeデータをバッファリングするため、CLI プログラムがたまたまパイプを明示的にフラッシュしない限り、バッファサイズのチャンクで受信しますが、私の場合はそうではありません。最初のコマンド プロンプトはバッファー サイズよりもはるかに小さいため、何も受信せず、そのまま待機します。ノーゴーNSPipeもそうです。

いくつかの調査の後、NSPipe の代わりに疑似端末(pty)を使用する必要があると判断しました。残念ながら、私はそれを機能させるのに問題がありました。

私が試したこと

stdout パイプの代わりに、次のように pty を作成します。

これにより、2 つのファイル記述子が得られます。これは、標準出力のみ、または標準出力と標準入力の両方でにslaveFD渡さNSFileHandleれます。NSTask次に、マスター側から通常の非同期読み取りを実行しようとします。

ターミナル ウィンドウで制御しているプログラムを実行すると、最初に 2 行のテキストが出力されます。1 行目は改行を含めて 18 バイト、もう 1 行は 22 バイトで、コマンド プロンプトに改行はありません。これらの 40 バイトの後、入力を待ちます。

stdout に pty を使用すると、制御対象のプログラムから 18 バイトの出力 (改行で終わる正確に 1 行) を受け取り、それ以上は受け取りません。最初の 18 バイトの後にすべてがそこに留まり、それ以上のイベントはありません。GCD イベント ソースのハンドラーは呼び出されません。

stdin にも pty を使用すると、通常は 19 バイトの出力 (前述の行と次の行の 1 文字) を受け取り、制御されたプログラムはすぐに終了します。データの読み取りを試行する前に少し待った場合 (またはスケジューリング ノイズによって少し一時停止した場合)、プログラムが再び即座に停止する前に、実際には 40 バイト全体を取得します。

追加の行き止まり

ある時点で、非同期読み取りコードに欠陥があるのではないかと考えていたので、NSFileHandles とその-readInBackgroundAndNotifyメソッドを使用してすべてをやり直しました。これは、GCD を使用する場合と同じように動作しました。NSFileHandle(私は当初、 API よりもGCD を選択しましたNSFileHandle。

質問

無駄な試みを 1 日以上続けた後、この時点にたどり着いたので、何らかの助けが必要でした。私がやろうとしていることには根本的な問題がありますか? 標準入力を pty に接続するとプログラムが終了するのはなぜですか? 私は pty のマスターエンドを閉じていないので、EOF を受け取るべきではありません。stdin は別として、なぜ 1 行分の出力しか得られないのですか? pty のファイル記述子で I/O を実行する方法に問題はありますか? マスターとスレーブ エンドを正しく使用していますか? マスターは制御プロセスで、スレーブは NSTask で?

私が試していないこと

これまでのところ、パイプと pty でノンブロッキング (非同期) I/O しか実行していません。私が考えることができる唯一のことは、pty が単にそれをサポートしていないということです。(そうであれば、なぜfcntl(fd, F_SETFL, O_NONBLOCK);成功するのでしょうか?) 代わりに、バックグラウンド スレッドでブロッキング I/O を実行して、メイン スレッドにメッセージを送信することができます。マルチスレッドに対処する必要がないようにしたかったのですが、これらすべての API が壊れているように見えることを考えると、非同期 I/O の別の順列を試すよりも時間がかかることはありません。それでも、私が間違っていることを正確に知りたいです。

私はzsshszを試してきましたがrz、ファイルを前後に (ローカル <-> リモート) にすばやく簡単に送信できるように思われるためですssh。問題は、リモートサーバーでbyobu(基本的にscreen) を使用していて、これが何らかの形でファイルの送受信と競合することです。

http://zssh.sourceforge.net/FAQ

第6号は次のように述べています。

実行byobuは私のリモート管理ツールキットの不可欠な部分であり、zssh.

zsshを無効にせずに作業する方法を考えられる人はいますbyobu/screenか? 私は自分でトラブルシューティングを行いますが、この種のことは私の頭を悩ませています (screenこのようなファイル送信プロセスと競合する理由がわからないため、説明が非常に役立ちます)。

また、この問題に対する代替の解決策をいただければ幸いです。

編集:からすぐにドロップアウトし、タスクをbyobu実行してから前のセッションに戻る 方法があるかどうか疑問に思っています...zsshbyobu

外部プロセスと対話する C++ プログラムを作成しています。外部プロセスは C# で記述されており、mono で実行されます。私が作成したプログラムではないため、C# コードを変更することはできません。

この点に関して、私は最初にパイプを使用することから始めました。もちろん後で気づいたように、パイプは完全にバッファリングされているため、多くの同期の問題に直面しました。基本的に、外部プロセスは書き込みごとに出力をフラッシュする必要があり、これは不可能でした。

次に試したのはファイルでしたが、私の場合は疑似端末を使用する方が適していることがわかりました。ここに私が書いたいくつかのサンプルコードがあります:

select の fdset と fdclr が処理されているとします。

親プロセスで次の問題が確認されています。

1. readBytes > 0 で read が返されることがありますが、バッファには何もありません。
2. ターミナルに書き込まれたものが読み戻されることがあります
3. ^]]49]1R などの一部のガベージ値が端末にダンプされています (これは実際の端末、つまり出力ウィンドウです)

PS: 外部プロセスが C/C++ で記述されている場合、この問題は発生しません。C# プログラムを mono で実行した場合のみ。