这看起来应该是一件非常简单的事情，不幸的是网页开发从来都不是我的强项。
我有一堆脚本，我想从网页启动它们，并在页面上看到实时的stdout文本。一些脚本需要很长时间才能运行，因此正常的单个响应不够好（我已经开始工作了）。
据我所知，我的选择是
stdout到一个文件，并定期（每隔几秒）从客户端发送一个请求并回复该文件的内容。
分块HTTP响应？我不确定这是否是他们所使用的 - 我试图实现这一点但我认为我可能误解了他们的目的。
Websockets（我正在使用Luvit服务器，所以这不是一个选项）。
......别的什么？
我确信必须有一种标准的实现方式，我看到其他网站一直这样做。以Teamcity为例。还是聊天室（vanilla TCP套接字？）。
任何正确方向的指针都会受到赞赏。最简单的方法，如果那只是从客户端发送大量的预定请求，那就这样吧。
答案 0 :(得分：2)
这让我想起了CGI。
你自己的想法听起来都是正确的方向。当您使用shell脚本，以及与Web服务器进行一些可能非常重要的交互时，我觉得指出在哪里挖掘这种代码的示例是很有意义的，这在很久以前很常见，并且非常错误 - 倾向，基本上总是。
实际上，你的脚本是一个CGI脚本，做着典型的事情。
在早期的互联网时代，这是实现网页的“常规方式”，不仅仅是静态文件（HTML或其他）。 该页面基本上是作为shell脚本（或从stdin读取并写入stdout的任何其他程序）实现的。
您正在做/提议的部分内容非常相似，我认为从旧的CGI代码中学习有很多有用的经验教训。
例如，通过sdtout从脚本内部获得正确的缓冲，通过Web服务器进入客户端的页面当然可能很棘手。
因此挖掘旧的例子可能会有很大帮助。
（这对你来说很明显，OP，个人，所以把“你”作为潜在的读者）
一般来说，棘手的部分将是缓冲，我期待。如果你习惯于在shell中显式处理stdin / out缓冲区，对于那些不支持它的程序，那些可以想象的东西可以想象 - 但如果不习惯它：我记得CGI更糟糕，因为你必须得到HTTP服务器的缓冲同步（让我们希望它自动处理） - 所以也许可以提早提问/挖掘例子。
CGI风格的方式正是你现在实现的 - 而缓冲是正确的，应该尽可能实时。但我知道你因为运行时间长而得到超时？或者你的运行时间变化很大？
就尽可能实时获取而言，没有比将stdout写入http流更好的了。
（我假设我们接受通过HTTP服务器的开销。）
另外，我正在考虑行缓冲，所以不要刷掉每个字符 - 这对用例来说是否足够好？ （即没有想要实时看到的动画进度指示线/ ANSI转义）
那么也许最好的方法是解决超时等问题，但要保持这个概念。如果实时不是那么重要，当然，其他方式在许多方面可能会更好。一点是任何可扩展性都可能需要其他方法。