有没有办法将外壳连接到伪tty? [英] Is there a way to connect a shell to a pseudo tty?
问题描述
如果我有一个(编译的)后台进程(在GNU/Linux上)，例如守护程序，则使用 openpty()或类似的方法为自己创建一个伪tty，有没有办法连接从外壳访问它，例如打开一个面向命令行的界面(例如，用于调试/即时配置它).
If I have a (compiled) background process (on GNU/Linux) such as a daemon create a pseudo-tty for itself, using openpty() or similar, is there a way to connect to it from the shell, for example to open a command line oriented interface (e.g. for debugging / re-configuring it on the fly).
这与这里的要求非常相似:
This is very similar to what is asked here:
有人建议使用 answer 在这里使用屏幕和minicom进行连接，但是我不清楚如何实现.我以为屏幕只能连接到由屏幕创建的屏幕.
Someone suggests an answer where they connect to it using screen and minicom but it is not that clear to me how. I had assumed screen could only connect to screens created by screen.
理想情况下，我想使用标准命令行工具连接到守护程序或者提供一个轻量级的程序来完成必要的工作.
Ideally I want to either use standard command line tools to connect to the daemon or provide a lightweight program that does the necessary.
目标是要比实现全面的客户端服务器实现(以及使用ttys)更简单.
The aim is for something simpler than going for a full scale client server implementation (and to play with ttys).
这是我最初的问题由于没有明确的重点而被关闭.我在这里有一个替补:
My original question was closed as lacking a clear focus. I have a replacement here:
将终端附加到作为守护进程运行的进程(以运行 ncurses UI)
这个问题集中在所描述用例的一个方面.如果我有一个以自己的pty运行的应用程序，那么有一种方法可以将该tty链接到现有的终端会话.
This question focuses on one aspect of the use case described. If I had an application running in its own pty is there a way of linking that tty to an existing terminal session.
实际上，该应用程序是后台的"，但在隐藏的终端中运行.您将如何使终端连接到该后台"终端.
Effectively the application is 'backgrounded' but running in a hidden terminal. How would you make your terminal connect to that 'backgrounded' one.
我认为您需要类似的东西:
I think you need something like:
- 一个选择循环，将stdin和stdout转发到pty的主端
- 将SIGWINCH转发给pty，以调整其大小以匹配您的终端(反之亦然).
推荐答案
该问题假定您只有一个服务器进程，但实际上您需要两个服务器进程.
The question presupposes you have a single server process but in fact you would need two.
一个过程是使用pty的从属端的后台"应用程序.
One process is your 'backgrounded' application using the slave end of the pty.
另一个过程是管理pty的主端的助手.主端必须始终保持打开状态.关闭主文件描述符后，将删除pty对.
The other process would be a helper which manages the master end of the pty. The master end must remain opened at all times. The pty pair is removed when the masters file descriptor is closed.
从属端的后台应用程序读取并写入其末尾.主机方决定如何处理这些读写操作.
The backgrounded applicaiton on the slave side, reads and writes to its end. The master side decides what to do with those reads and writes.
要从另一个终端进行连接，您需要告诉主端将读写发送到哪里.
To connect from another terminal you need to tell the master end where to send the read and writes.
您可以使用某种方式为它指定pty终端的名称.然后，管理主端的进程可以根据需要转发读写操作.
You could give it the name of the pty terminal you are using somehow. The process managing the master end could then forward the reads and writes as appropriate.
仅此一项不足以用于某些应用程序.特别是如果终端的大小发生变化，则应用程序应接收 SIGWINCH .主机将需要以某种方式将此传递给从机.终端功能也可能有所不同，需要翻译.
This alone is insufficient for some applications. In particular if the terminal's size is changed the application should recieve a SIGWINCH. The master will need to pass this to the slave somehow. The terminal capabilities could also differ and require translation.
要处理这些问题，您的客户端需要第三个进程，该进程与运行pty的主端的进程进行通信.这是屏幕和 tmux 的工作方式.
To handle those your client side needs a third process which talks to the process running the master end of the pty. This is how screen and tmux work.
因此，没有标准程序可以执行您想要的操作，因为没有标准方法可以处理此问题.屏幕之类的程序可以按照自己的方式进行操作，但在大多数情况下都可以照常使用.
So there is no standard program that does what you want because there is no standard way to handle this. Programs like screen do this their own way but can be used as is in most cases.
In an answer to the linked question the OP (of that question) uses a terminal in raw mode which probably means those complications do not apply. For example if you just want to forward stdout from the master a pty name to duplicate the output to would be sufficient.
另一方面， screen 程序为每个虚拟屏幕创建一个套接字(在pty的主端运行).与客户端进程运行(以不同模式运行)的同一 screen 可执行文件连接到该套接字以与应用程序通信.
The screen program on the other hand creates a socket for each virtual screen (running on the master side of the pty). The same screen executable running (in a different mode) as a client process connects to that socket to talk to the application.
鉴于屏幕和tmux是专门为执行此操作而设计的，尚不清楚您自己执行此操作会带来什么好处.但是，这可能是一个有趣的学习练习.
Given that screen and tmux are designed explicitly to do this it is not clear what advantage you would gain from doing this yourself. It could be an interesting learning exercise however.
The new question describes your use case better.
You could not create new user interfaces on demand with screen.
It does handle the foreground and background use case very nicely so long as you remember to run the process under screen from the outset, where screens attach and detach command would replace direct use of bg and fg.
这篇关于有没有办法将外壳连接到伪tty?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
