Asciinema: 实时写入磁盘

好收获@vvv。 看起来它可以很容易地修复。

我看着这个。 目前的想法：

asciinema 不会即时生成 JSON 流 - 它会生成整个 JSON 字符串，并在捕获整个 stdout 后将其保存到文件中。 这主要是因为 Go 的 JSON marshaller 是如何工作的。

一种可能性是刷新到 tmp 文件（ foo.json.tmp如果您记录到foo.json ）。 它可能看起来像：

{ "version": 2, "width": 80, "height": 24, "env": { "TERM": "xterm-256color" } ... }
[0.1, "bash-4.3$ "]
[0.3, "l"]
[0.1, "s"]
...
...

基本上是一个具有多个顶级对象的 JSON 文件，首先是带有元数据的 JSON 映射，其余的都是标准输出打印，最终应该在最终文件中的stdout键下结束。

至于恢复，您可以自己轻松完成（只需在 vim 中移动行）。
也可能有一个新命令asciinema recover foo.json.tmp foo.json来自动执行此操作（不确定将恢复作为asciinema play是否最好）。

一种可能性是刷新到 tmp 文件（ foo.json.tmp如果您记录到foo.json ）。

听起来不错！ 此功能类似于 Emacs 的自动保存文件( #foo.json# ) 和 Vim恢复文件( .foo.json.swp 。)

至于恢复，您可以自己轻松完成（只需在 vim 中移动行）。

坦率地说，我更喜欢“恢复”命令，甚至是轻量级的-r | --recover选项，而不是手动摆弄自动保存文件。

只是为了公开说明这一点，#82 也会解决这个问题。

@xloem #82 仅适用于您一步 rec+upload 到 asciinema.org 的情况。 asciinema rec demo.json还允许您在不自动上传到站点的情况下记录到文件，并且在这种情况下增量写入磁盘同样有用。

我开始在 #196 中编写asciicast v2格式的草案，它应该可以很好地解决实时写入磁盘（以及管道、网络，你有什么）的问题。

此 PR 的直接链接： https :

反馈高度赞赏。

@sickill我看不到文件格式的更改（ NDJSON而不是 JSON）如何应用于输出文件的增量更新。 你能解释一下吗？

@vvv在普通的 JSON 文件中，你有一个对象，你不能增量写入它，它必须作为一个整体写入（技术上你可以，但如果你崩溃等，那么你最终会得到无效的 JSON 文件，错过了结束括号）。 使用 NDJSON（或几乎相同的JSONLines ），您可以在单个文件中拥有多个 JSON 对象，每个对象都在自己的行上。 因此，您可以使用新数据附加新行并随意停止/崩溃，并且永远不会使文件无效。

我已经更新了 asciicast v2 格式文档的草案，以使其更清楚地了解动机/它解决了什么问题。

@sickill 最好的一件事是将会话的开始时间存储在初始元数据中。 这可以在其他工具中提取以提供可审计的 ssh 会话。

此外，能够“注入”元数据可能很有趣，因此您可以使用以下内容标记创建的会话：

• 使用 ssh 的用户
• 主机名
• 服务器环境

并将其暴露在一些外部用户界面中。

编辑：似乎格式有公关，所以我会在那里发表评论:)

我目前已经为远程员工的会话日志设置了 asciinema
通过跳转主机通过 ssh 连接到安全网络。 能够保存，
流和重放会话，当它们发生时，将大大增强
asciinema 在上述场景中的用处。

2017 年 4 月 25 日，星期二，上午 5:17，Jose Diaz-Gonzalez <
[email protected]> 写道：

@sickill https://github.com/sickill一件好事
将会话的开始时间存储在初始元数据中。
这可以在其他工具中提取以提供可审计的 ssh 会话。

此外，能够“注入”元数据可能很有趣，因此您
可能会使用以下内容标记创建的会话：

• 使用 ssh 的用户
• 主机名
• 服务器环境

并将其暴露在一些外部用户界面中。

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/asciinema/asciinema/issues/127#issuecomment-296872546 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAi2o-cZFmoJOnPeabG0UkPfb8MVR3EMks5rzVfNgaJpZM4FuWm_
.

我使用 asciinema（嗯，不再使用了，因为这个问题，我将恢复到脚本）来记录我所有终端会话到 CYA 以及如果我忘记了我上周在服务器 X 上所做的事情 3 时的参考下午。 问题是，因为这只会在成功退出时刷新，所以我的一半会话没有数据。 例如，关闭挂起会话的窗口会导致会话记录完全丢失。 这是出乎意料的行为，非常令人失望。

@gizmonicus asciicast v2 格式和实时写入磁盘是下一个版本的最高优先级。 没有预计到达时间，但这很快就会发生。

@sickill - 谢谢，很高兴听到这个消息。 我会留意的。 我真的更喜欢 asciinema 而不是脚本，因为我可以将内容嵌入到我们的 Wiki 中以供其他系统管理员使用。

@timofonic您可以在这里提出您的问题并耐心等待。 没有必要通过这种方式 ping 用户来向所有人发送垃圾邮件。

更新：实时写入磁盘已在 #196 中实现，并将成为下一个版本的一部分。

如果您想对它进行 beta 测试，请检查develop分支并从结帐目录运行它： python3 -m asciinema rec filename 。 我非常感谢有关它在各种 Linux 发行版和 macOS 上如何工作的反馈 👋

注意：截至今天服务器和网络播放器不支持新的 asciicast 格式，因此只能用于本地录制和终端内播放。

伟大的工作@sickill！ 我刚刚测试了这个并且能够让它工作（Ubuntu 17.04）。

不过要澄清一点； 什么触发转储？ 是文件缓冲还是超时？ 无论哪种方式，具体的阈值是多少？ 我问是因为在做了几次快速回声之后，我没有在文件中看到任何东西，但是当我更多地玩弄它时，东西开始出现。

@metasoarous这是一个很好的问题。

没有明确的超时或任何其他机制来批量写入，它通过队列实时进行：

https://github.com/asciinema/asciinema/blob/8e1b6f7da1a0ad4d52e63998b14c1a5133fc7836/asciinema/asciicast/v2.py#L72

分离“作家”过程：

https://github.com/asciinema/asciinema/blob/8e1b6f7da1a0ad4d52e63998b14c1a5133fc7836/asciinema/asciicast/v2.py#L36 -L40

这样做f.write(...) 。

话虽如此，我还观察到它是以大约 8KB 的块写入的，所以这里肯定有一些缓冲。 我怀疑是 Python 的TextIOWrapper在这里负责。

你认为这里最好的是什么？ 我们可以在打开的 io 对象上关闭缓冲，或者实现显式触发器，在每次写入时f.flush() ，或者在达到阈值时进行字节/时间计数和刷新。

我想关闭 io 对象的缓冲可能是最简单的解决方案，每 N 秒手动刷新一次。 我可以想象更高级的策略，但接近这些选择之一的东西应该可以解决问题。

我改变了它，所以它现在在打开文件进行写入时明确地将缓冲策略设置为“行缓冲”（== 当写入包含\n时刷新，在我们的例子中是 100% 的写入）。 如果您现在拉动并尝试它，您应该会立即看到文件增长。

精彩的！ 非常感谢您的快速关注！

鉴于此已实施（在 #227 中）并将与即将发布的 asciinema 2.0 一起发布，我将关闭此问题。

注意：如果有人想尝试这个然后结帐v2分支。