FreeStyleWiki

pty周りの調査

このエントリーをはてなブックマークに追加

[Linux,ReactOS]

pty周りの調査

  概要

UNIXにおけるテキスト端末の擬似デバイスのマスター・スレーブのペア

昔はテキスト端末が実物で存在していた、それの疑似だから疑似端末

Unix98 PTY

multiplexerデバイス(通常 /dev/ptmx)を含むSystem V由来のいくつかのシステムでは、

オープンの際に最初の利用可能なマスターデバイスに関連付けられたディスクリプタを返す。スレーブデバイスは /dev/pts/1 などになる。

現在は Unix98 PTY の方がより頻繁に使われている。

Linuxで使われているやつの仕様もUnix98 PTYか

通常、Linuxの場合、最初の6つの仮想コンソール (/dev/tty1〜/dev/tty6) がUnixシェルへのログインプロンプトが表示されたテキストターミナルである。

ptyに対して仮想コンソールで接続する。

イメージ

from Windows Command-Line: Introducing the Windows Pseudo Console (ConPTY)

  NTとかWindowsのptyについて

Windowsのptyについて包括的な読み物があったので読む

Windows Command-Line: Introducing the Windows Pseudo Console (ConPTY)

UNIXのPTYについて

This PTY infrastructure is used extensively by *NIX Terminal applications, text pane managers (like screen, tmux), etc.

Such apps call openpty() which returns a pair of file descriptors (fd) for the PTY’s master and slave. The app can then fork/exec the child Command-Line application (e.g. bash), which uses its slave fds to listen and return text to the attached Terminal.

This mechanism allows Terminal applications to “talk” directly to Command-Line applications running locally in the same way as the Terminal would talk with a remote Computer via a serial/network connection.

このPTYインフラストラクチャは、UNIX系のターミナルアプリケーション、テキストペインマネージャー(screen、tmuxなど)などで広く使用されています。

このようなアプリはopenpty()を呼び出し、PTYのマスターとスレーブのファイル記述子(fd=ファイルディスクリプタ)のペアを返します。 次に、アプリは子コマンドラインアプリケーション(bashなど)をフォーク/実行できます。このアプリケーションは、スレーブのfdを使用して、接続されたターミナルにテキストをリッスンして返します。

このメカニズムにより、ターミナルアプリケーションは、シリアル/ネットワーク接続を介してリモートコンピュータと通信するのと同じ方法で、ローカルで実行されているコマンドラインアプリケーションと直接「通信」できます。

WindowsのPTYの事情について

What, no Windows Pseudo Console?

なぜ、Windowsには疑似端末がない?

1. Windows lacks a PTY infrastructure: When the user launches a Command-Line app (e.g. Cmd, PowerShell, wsl, ipconfig, etc.), Windows itself “hooks up” a new or existing Console instance to the app

2. Windows obstructs 3rd party Consoles and Server Apps: Windows (currently) does not provide Terminals a way to supply the communication pipes via which it wants to communicate with a Command-Line app. 3rd party Terminals are forced to create an off-screen Console, and to send it user-input and scrape its output, redrawing the output on the 3rd party Console’s own display!

3. Only Windows has a Console API: Windows Command-Line apps rely on the Win32 Console API which reduces code portability because every other platform “speaks text/VT” rather than calling APIs

4. Windows Command-Line Remoting is substandard: Windows’ Command-Line apps’ dependence on Console API significantly impedes interop & remoting scenarios

  1. WindowsにPTYインフラストラクチャがない:ユーザーがコマンドラインアプリ(Cmd、PowerShell、wsl、ipconfigなど)を起動すると、Windows自体が新規または既存のコンソールインスタンスをアプリに「接続」します
  2. Windowsがサードパーティのコンソールとサーバーアプリを妨害する:Windowsは(現在)ターミナルに、コマンドラインアプリとの通信に使用する通信パイプを提供する方法を提供していません。 サードパーティの端末は、画面外のコンソールを作成し、ユーザー入力を送信してその出力をスクレイプし、サードパーティのコンソール自体のディスプレイに出力を再描画するように強制されます。
  3. WindowsのみにコンソールAPIがあります。WindowsコマンドラインアプリはWin32コンソールAPIに依存しており、他のすべてのプラットフォームはAPIを呼び出すのではなく、「テキスト/ VTを話す」ため、コードの移植性が低下します。
  4. Windowsコマンドラインリモーティングは標準以下です:WindowsのコマンドラインアプリがコンソールAPIに依存しているため、相互運用とリモーティングのシナリオが大幅に妨げられます

→ このブログ自体はこのような事情から、新しく作られたWindows用のPTYであるconptyについて紹介して締めている。

一方でCygwin/mintty/winptyなどの構造はどうなっているのか

  mintty

http://mintty.github.io/

Mintty works on all Windows versions from Windows XP onwards. Similarly to other Cygwin/MSYS terminals based on pseudo terminal ("pty") devices.

Windows console input/output (as used by native Windows command-line programs) has interworking problems with "pty" mode (most notably character set, but also character-wise input and signal processing incompatibilities, see input/output interaction).

Cygwin 3.1.0 compensates for this issue via the ConPTY API of Windows 10.

Minttyは、WindowsXP以降のすべてのWindowsバージョンで動作します。 疑似端末(「pty」)デバイスに基づく他のCygwin/MSYS端末と同様です。Windowsコンソールの入力/出力(ネイティブのWindowsコマンドラインプログラムで使用される)には、「pty」モードでの相互作用の問題があります(特に文字セットですが、文字ごとの入力と信号処理の非互換性もあります。入力/出力の相互作用を参照してください)。Cygwin 3.1.0は、Windows10のConPTYAPIを介してこの問題を補正します。

「pty」モードでの相互作用の問題

https://github.com/mintty/mintty/wiki/Tips#inputoutput-interaction-with-alien-programs

When interacting with programs that use a native Windows API for command-line user interaction (“console mode”), a

number of undesirable effects used to be observed; this is the pty incompatibility problem and the character encoding incompatibility problem.

This would basically affect all programs not compiled in a cygwin or msys environment

(and note that MinGW is not msys in this context), and would occur in all pty-based terminals (like xterm, rxvt etc).

Cygwin 3.1.0 compensates for this issue via the ConPTY API of Windows 10. On MSYS2,

its usage can be enabled by setting MSYS=enable_pcon or changing the default during installation.

As a workaround on older versions of Cygwin or Windows, you can use winpty as a wrapper to invoke the Windows program.

コマンドラインユーザー操作(「コンソールモード」)を使用するためにネイティブWindows APIを使ってプログラムを操作する場合、望ましくない影響が数多くあります。 というのは、ptyの非互換性の問題と文字エンコードの非互換性の問題です。これは基本的に、cygwinまたはmsys環境でコンパイルされていないすべてのプログラムに影響します(そして、MinGWはこのコンテキストではmsysではないことに注意してください)、すべてのptyベースの端末(xterm、rxvtなど)で発生します。Cygwin 3.1.0は、Windows10のConPTYAPIを介してこの問題を補正します。MSYS2では、その使用法は、MSYS = enable_pconを設定するか、インストール中にデフォルトを変更することで有効にできます。古いバージョンのCygwinまたはWindowsでの回避策として、winptyをラッパーとして使用してWindowsプログラムを呼び出すことができます。