問題タブ [tty]

多くのユーザーが使用できるように、スクリプトが書き込まれたログイン情報を取得したいと思います。Python では、input_raw を dev/tty から読み取るように設定しましたが、サーバー上で実行されているスクリプトに ssh 経由で接続すると、ひどく失敗します。

考え？回避策？

ユーザー名をスクリプトにハードコーディングすることは避けたいと思います。

よろしくお願いします。

ターミナルと通信するサードパーティによって開発された Linux プロセスがあります。デバッグのために、通信が行き来するのを見たいです。

cat（一方向を見るために）トリックを行うと思うかもしれません：

...しかし、そうではありません。むしろ、catアプリケーション向けのデータの半分を盗みますが、これはほとんど価値がありません。

third-party-app は、想定するようにハードコーディングされて/dev/ttyいます。

通信をスパイするために私が見つけた 1 つの方法は、/dev/ttyデバイスの名前を変更し、その場所で/dev/real_tty呼び出される名前付きパイプを作成することです。/dev/tty次に実行します：

... から名前付きパイプにデータ/dev/real_ttyをコピーすることで、少なくとも の出力を確認できます。/dev/real_tty/dev/ttystdout

この種の機能は機能しますが、非常に危険な感じがし、デバイスを交換するという巧妙な方法に依存しています。また、名前付きパイプは一方向にしかデータを伝送しないため、双方向には機能しません。

これを行う正しい方法は何ですか？

不思議に思っている方のために説明すると、TTY デバイスはマイクロコントローラーへの RS-232 リンクです。情報は機密でも安全でもありません。すべてのプロセス (アプリケーションとスパイ) は root として実行できます。

この Python コードに相当する Perl を探しています。

(DEBUG) 印刷が有効になっているライブラリを使用するコンソール アプリケーションを作成しています。私の main() アプリケーションでは、ユーザーからの入力を取得しています。このユーザー入力をライブラリの印刷物とは別にしたいと考えています。ライブラリのデバッグ プリントを無効にできません。（問題は、ライブラリにユーザー入力を取得するのが難しい連続印刷がたくさんあることです。ユーザー入力を取得するための新しい tty を作成するようなことはできますか。）

それとも、何らかのプロセスまたは何かが仮想端末をブロックする可能性はありますか? または、VT1 にアクセスしようとしたときにアプリケーションがハングする理由は何でしょうか?

それが起こっている間、関数にぶら下がっているようioctlです。特に、これは失敗するコードです:

2 番目にハングしますioctl。中断すると、次のメッセージが表示されます。

また、そこで待機している間に、chvt 1別の端末から a を実行すると、それもハングします。

私はphpスクリプトを書きました。インタラクティブに読み取って実行する前に、ttyデバイス（端末）に接続された標準入力で呼び出されたときにヘルプメッセージを表示したいのですが、標準入力としてパイプからのファイルまたはストリームで呼び出されたときに表示されません。

PHPからこれを検出する方法はありますか？

PHP のコマンド ラインから一度に 1 文字ずつ読み取りたいのですが、どこかからの何らかの入力バッファリングがこれを妨げているようです。

次のコードを検討してください。

入力として「foo」と入力して（Enterキーを押して）、得られる出力は次のとおりです。

私が期待している出力は次のとおりです。

(つまり、入力時に文字が読み取られ、処理されます)。

ただし、現在、各文字は、Enter キーが押された後にのみ読み取られます。TTY が入力をバッファリングしている疑いがあります。

最終的には、上矢印、下矢印などのキー押下を読み取れるようにしたい.

私はいつも、printステートメントで端末に出力するのにかかる時間に驚かされたりイライラしたりしてきました。最近の痛々しいほど遅いロギングの後、私はそれを調べることにしました、そして、費やされたほとんどすべての時間が端末が結果を処理するのを待っているのを見つけて非常に驚きました。

stdoutへの書き込みをなんとかスピードアップできますか？

print_timer.pystdout、ファイル、およびstdoutにリダイレクトされた100k行を書き込むときのタイミングを比較するために、スクリプト（この質問の下部にある' '）を作成しました/dev/null。タイミングの結果は次のとおりです。

わお。stdoutを/dev/ nullなどに再割り当てしたことを認識するなど、Pythonが舞台裏で何かを行っていないことを確認するために、スクリプトの外部でリダイレクトを行いました...

つまり、これはPythonのトリックではなく、単なる端末です。私はいつも/dev/ nullに出力をダンプすることで物事がスピードアップすることを知っていましたが、それがそれほど重要であるとは思いもしませんでした！

ttyがどれほど遅いかは私を驚かせます。物理ディスクへの書き込みが「画面」（おそらくすべてRAM操作）への書き込みよりもはるかに高速であり、/ dev / nullを使用してガベージにダンプするのと同じくらい効果的に高速であるのはどうしてですか？

このリンクでは、端末がI / Oをブロックして、「[入力]の解析、フレームバッファーの更新、ウィンドウをスクロールするためのXサーバーとの通信など」を行う方法について説明しています...しかし、私はしません完全にそれを取得します。何がそんなに時間がかかるのでしょうか？

（より高速なtty実装がないのですか？）解決策はないと思いますが、とにかく質問したいと思います。

更新：いくつかのコメントを読んだ後、私は自分の画面サイズが実際に印刷時間にどの程度の影響を与えるのか疑問に思いました、そしてそれはいくつかの重要性を持っています。上記の非常に遅い数値は、私のGnomeターミナルが1920x1200まで膨らんだ状態です。小さくすると非常に小さくなります...

それは確かに良いです（〜4x）が、私の質問は変わりません。ターミナル画面のレンダリングによってアプリケーションのstdoutへの書き込みが遅くなる理由がわからないため、これは私の質問に追加されるだけです。プログラムが画面レンダリングの続行を待つ必要があるのはなぜですか？

すべてのターミナル/ttyアプリが同じように作成されていませんか？私はまだ実験していません。端末はすべての着信データをバッファリングし、それを目に見えない形で解析/レンダリングし、現在の画面構成に表示されている最新のチャンクのみを適切なフレームレートでレンダリングできる必要があるように思えます。したがって、ディスクへの書き込み+ fsyncを約0.1秒で実行できる場合、端末は同じ操作をその順序で完了できるはずです（実行中に画面が数回更新される可能性があります）。

プログラマーにとってこの動作を改善するために、アプリケーション側から変更できるtty設定があることを私はまだ望んでいます。これが厳密にターミナルアプリケーションの問題である場合、これはStackOverflowに属していない可能性がありますか？

私は何が欠けていますか？

タイミングを生成するために使用されるPythonプログラムは次のとおりです。

私はJavaプログラムを持っています.Test.classとしましょう。

Java Test を実行すると、プログラムはパスワードを要求してから続行します。

問題は、stdout がログにリダイレクトされ、プログラムが & で起動されることです (ここでは UNIX を使用しています)。

Java Test を起動したこのプログラムと stdin および stdout を使用して対話するにはどうすればよいですか?

考えられる解決策の 1 つは、プログラムをフォアグラウンドで開始し、条件の後で Java からバックグラウンドで実行することです。

ありがとう！

ユーザーが私の小さなデバイスに接続して、システムの現在の標準入出力を「引き継ぐ」ことができる単純なリモート管理プログラムを作成しようとしています。例えば：

システムは console=serial port で起動します --> クライアントが接続し、入力/出力をソケットにリダイレクトします

Linuxのpty機能を使用して、ネットワーク部分へのリダイレクトをすでに完了しています（多くのmanページを読むことで。男、今までこれらのmanページを高く評価したことはありません！:D）。

openpty() -> grantpt() -> unlockpt() --> クライアントが接続し、login_tty() を実行

私のプログラムは、マスター FD とソケットの監視を処理します。ただし、大きな問題があります。出力をリダイレクトする方法がわかりません。私は次のことを試しました：

o シリアルポートファイルを開くハードコード

o login_tty() で開かれたシリアルポートファイルを使用する

しかし、それは機能していないようです (プロセスグループに関する何かと、最初の login_tty() を実行した後のプロセスグループのリーダーであること)。提案やアイデアはありますか？

login_tty() にはある種の「逆」関数がありますか?