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