问题标签 [tty]

我会为编写的脚本获取一些登录信息以供许多用户使用。在 python 中，我将 input_raw 设置为从 dev/tty 读取，但是当我通过 ssh 连接到在服务器上运行的脚本时，它严重失败。

想法？解决方法？

我宁愿避免将用户名硬编码到脚本中。

谢谢，麻烦您了。

我有一个由第三方开发的与终端通信的 Linux 进程。对于调试，我希望看到通信返回。

有人可能会认为cat可以解决问题（看到一个方向）：

...但事实并非如此。相反，cat会窃取一半用于应用程序的数据，这几乎毫无价值。

third-party-app 被硬编码为假设/dev/tty.

我发现监视通信的一种方法是将/dev/tty设备重命名为，比如说，/dev/real_tty并创建一个命名管道/dev/tty来代替它。然后运行：

...至少会让我看到 的输出，方法是将数据从命名管道/dev/real_tty复制到./dev/real_tty/dev/ttystdout

这种工作但感觉真的很狡猾，并且依赖于更换设备的诡计。它也不能双向工作，因为命名管道只能在一个方向上传输数据。

这样做的正确方法是什么？

如果有人想知道，TTY 设备是与微控制器的 RS-232 链接。该信息不敏感或不安全。所有进程（应用程序和间谍）都可以作为 root 运行。

我正在寻找与此 Python 代码等效的 Perl：

我正在编写一个控制台应用程序，它使用了一些启用了（调试）打印的库。在我的 main() 应用程序中，我从用户那里获取输入。我希望这个用户输入与我的图书馆打印分开。我不能禁用库调试打印。（问题是库有很多连续打印，很难接受用户输入。我可以做一些事情，比如创建一个新的 tty 来接受用户输入。）

或者是否有可能某些进程或其他东西可能会阻塞虚拟终端？或者在尝试访问 VT1 时应用程序挂起的原因可能是什么？

似乎，在发生这种情况时，它挂在了 function 中ioctl。特别是，这是失败的代码：

它挂在第二个ioctl。当我打断它时，我收到以下消息：

此外，当它在那里等待时，如果我chvt 1从另一个终端执行，那也会挂起。

我写了一个php脚本。我希望它在以连接到 tty 设备（终端）的标准输入调用时显示帮助消息，然后以交互方式读取和执行，但在使用来自管道的文件或流作为标准输入调用时不显示。

有没有办法从 PHP 中检测到这一点？

我想从 PHP 的命令行一次读取一个字符，但是似乎有某种输入缓冲从某处阻止了这一点。

考虑这段代码：

输入“foo”作为输入（并按回车键），我得到的输出是：

我期待的输出是：

（也就是说，字符在输入时被读取和处理）。

但是，目前，每个字符只有在按下 enter 后才会被读取。我怀疑 TTY 正在缓冲输入。

最终我希望能够阅读诸如向上箭头、向下箭头等按键。

I've always been amazed/frustrated with how long it takes to simply output to the terminal with a print statement. After some recent painfully slow logging I decided to look into it and was quite surprised to find that almost all the time spent is waiting for the terminal to process the results.

Can writing to stdout be sped up somehow?

I wrote a script ('print_timer.py' at the bottom of this question) to compare timing when writing 100k lines to stdout, to file, and with stdout redirected to /dev/null. Here is the timing result:

Wow. To make sure python isn't doing something behind the scenes like recognizing that I reassigned stdout to /dev/null or something, I did the redirection outside the script...

So it isn't a python trick, it is just the terminal. I always knew dumping output to /dev/null sped things up, but never figured it was that significant!

It amazes me how slow the tty is. How can it be that writing to physical disk is WAY faster than writing to the "screen" (presumably an all-RAM op), and is effectively as fast as simply dumping to the garbage with /dev/null?

This link talks about how the terminal will block I/O so it can "parse [the input], update its frame buffer, communicate with the X server in order to scroll the window and so on"... but I don't fully get it. What can be taking so long?

I expect there is no way out (short of a faster tty implementation?) but figure I'd ask anyway.

UPDATE: after reading some comments I wondered how much impact my screen size actually has on the print time, and it does have some significance. The really slow numbers above are with my Gnome terminal blown up to 1920x1200. If I reduce it very small I get...

That is certainly better (~4x), but doesn't change my question. It only adds to my question as I don't understand why the terminal screen rendering should slow down an application writing to stdout. Why does my program need to wait for screen rendering to continue?

Are all terminal/tty apps not created equal? I have yet to experiment. It really seems to me like a terminal should be able to buffer all incoming data, parse/render it invisibly, and only render the most recent chunk that is visible in the current screen configuration at a sensible frame rate. So if I can write+fsync to disk in ~0.1 seconds, a terminal should be able to complete the same operation in something of that order (with maybe a few screen updates while it did it).

I'm still kind of hoping there is a tty setting that can be changed from the application side to make this behaviour better for programmer. If this is strictly a terminal application issue, then this maybe doesn't even belong on StackOverflow?

What am I missing?

Here is the python program used to generate the timing:

我有一个java程序，比如说Test.class。

当我执行 java Test 程序要求输入密码然后继续。

问题是标准输出被重定向到日志并且程序使用 & 启动（我们在 UNIX 上）。

我如何与这个程序启动 java Test & 与标准输入和标准输出进行交互？

一种可能的解决方案是在前台启动程序，然后在某个条件下从 java.util.Run 后台运行它。

谢谢！

我正在尝试创建一个简单的远程管理程序，用户可以在其中连接到我的小设备并“接管”系统的当前 stdio。例如：

系统启动时使用控制台=串行端口 --> 客户端连接，将输入/输出重定向到套接字

我已经使用 Linux 的 pty 功能完成了对网络部分的重定向（通过阅读大量手册页。伙计，直到现在我才欣赏这些手册页！:D）。

openpty() -> grantpt() -> unlockpt() --> 客户端连接，执行 login_tty()

然后我的程序处理主 FD 和套接字的监视。但是，我有一个大问题：我不知道如何将输出重定向回来。我尝试了以下方法：

o 硬编码打开串口文件

o 在 login_tty() 中使用打开的串口文件

但它似乎不起作用（关于进程组和在执行第一个 login_tty() 后成为进程组的领导者）。有什么建议或想法吗？

login_tty() 是否具有某种“逆”功能？