将stdout流式传输到网页 [英] Streaming stdout to a web page

问题描述

这似乎应该是一个非常简单的事情，不幸的是，网页开发从来都不是我的强项。

This seems like it should be a really simple thing to achieve, unfortunately web development was never my strong point.

我有一堆脚本，我会喜欢从网页启动它们，并在页面上看到实时的stdout文本。一些脚本需要很长时间才能运行，所以正常的单一响应不够好（我已经有了这个工作）。

I have a bunch of scripts, and I would like to launch them from a webpage and see the realtime stdout text on the page. Some of the scripts take a long time to run so the normal single response isn't good enough (I have this working already).

据我所见，我的选项是

• stdout到文件，并定期（每隔几秒）从客户端发送请求并回复这个文件的内容。

• stdout to a file, and periodically (every couple of seconds) send a request from the client and respond with the contents of this file.

分块的HTTP响应？我不确定这是否是他们所使用的 - 我试图实现这一点但我认为我可能误解了他们的目的。

Chunked HTTP responses? I'm not sure if this is what they are used for- I tried to implement this already but I think I may be misunderstanding their purpose.

Websockets（我正在使用Luvit服务器，所以这不是一个选项。）

Websockets (I'm using a Luvit server so this isn't an option).

......还有别的吗？

... Something else?

我确信必须有一种标准的实现方式，我看到其他网站一直这样做。以Teamcity为例。还是聊天室（vanilla TCP套接字？）。

I'm sure there must be a standard way of achieving, I see other sites doing this all the time. Teamcity for example. Or chat rooms (vanilla TCP sockets?).

任何正确方向的指针都会受到赞赏。最简单的方法，如果那只是从客户端发送大量的预定请求，那就这样吧。

Any pointers in the right direction appreciated. Simplest method possible, if that's just sending lots of scheduled requests from the client then so be it.

推荐答案

这让我想起了很多 CGI 。

您自己的想法是否合理都是正确的方向。当您使用shell脚本以及与Web服务器进行一些非常重要的交互时，我觉得指出在哪里挖掘这种代码的示例是很有意义的，这在很久以前很常见，并且非常错误 - 倾向，基本上总是。

Your own ideas sound all like the right direction. As you are using a shell script, and some potentially nontrivial interactions with the web server, I feel it could make sense to point out where to dig for examples of this kind of code, which was common a long time ago, and very error-prone, basically allways.

实际上，你的脚本是一个CGI脚本，做典型的事情。

Practically, your script is a CGI script, doing typical things.

在早期的互联网时代，这是实现网页的常规方式，不仅仅是静态文件（HTML或其他）。
该页面基本上是作为shell脚本实现的（或者从stdin读取并写入stdout的任何其他程序）。

In the earlier days and years of the internet, that was the "normal way" to implement web page that are not just static files (HTML or others). The page is basically implemented as a shell script (or any other programm reading from stdin and writing to stdout).

你正在做/提议的部分内容非常相似，我认为从旧的CGI代码中学习有很多有用的经验教训。

例如，通过sdtout从脚本内部获取正确的缓冲，通过Web服务器进入客户端页面可能会很棘手当然。
因此，挖掘旧的例子可能会有很大的帮助。

Part of what you are doing/proposing is very similar, and I think there are useful lessons to learn from old CGI code.
For example, getting buffering right with from inside the script over sdtout, whrough the web server onto the client's page can be tricky of course. So digging out old examples could help a lot.

（这对你来说很明显，OP，个人而言，所以你作为潜在的读者）

一般来说，棘手的部分是缓冲，我期待。如果你习惯于在shell中显式处理stdin / out缓冲区，对于那些不支持它的程序，那些可以想象的东西可以想象 - 但如果不习惯它：我记得CGI更糟糕，因为你必须得到HTTP服务器的缓冲同步（让我们希望它自动处理） - 所以可能会开始提问/早期挖掘例子。

(Much of this may be obvious to you, the OP, personally, so take the "you" as potential reader)
The tricky part in general will be the buffering, I expect. If you are used to explicitly handling stdin/out buffers in shell, for programms that do not support it, the kind of things to expect can be imagined - but if not used to it: I remember CGI is worse, as you have to get the buffering of the HTTP server in sync too (let's hope it is handled automatically) - so maybe start to ask questions/dig for examples early.

CGI风格的方式正是你现在实现的 - 而且缓冲是正确的，应该尽可能实时。但我知道你因为运行时间长而得到超时？或者你的运行时间变化很大？

The CGI style way would be exactly what you have implemented now - and it the buffering is right, that should be as real-time as it can get. But I understand that you get timeouts because of the long runtime? Or do you have strongly varying runtimes?

在尽可能实时地获取它时，没有比将stdout写入http流更好的了。

（我假设我们接受通过HTTP服务器的开销。）
另外，我正在考虑行缓冲，所以不要刷新每个字符 - 这对用例来说是否足够好？ （即没有你想要实时看到的动画进度指示线/ ANSI转义）

那么也许最好是解决超时等问题，但要保持这个概念。如果实时不是那么重要，当然，其他方式在许多方面可能会更好。一点是任何可扩展性都可能需要其他方法。

In terms of getting it as real-time as possible, there is nothing better than writing stdout to the http stream.
(I assume we accept the overhead of going through a HTTP server.) Also, I'm thinking of line buffering, so not flushing every char - is that good enough for the use case? (i.e. no animated progress indicator lines/ ANSI escapes that you want to see in real time)
Then maybe the best is to work aroung the issues like timeouts, but to keep the concept. If real time is not that important, other ways may be better in many ways, of course. One point would be that other methods could be required for any scalability.

这篇关于将stdout流式传输到网页的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！