I have built a tool allowing the asciicast file format to be used for session recording, monitoring and playback, to be used in security and compliance scenarios.
I propose that the v3 file format be enhanced to enable better support for terminal session capture for analysis purposes rather than for entertainment purposes.
Specifically I propose that you add support for a stderr record type with a value of “e”. This would allow the recorder to separately record stderr enabling enhanced analysis of sessions. It can be optional to record and optional to do anything with at playback time, but players should not emit an error if they encounter the record and it’s well-formed.
The specific format would follow the format of the other record types, e.g. [interval, code, data].
The code would be “e”. The data would contain whatever was captured on stderr.
An example record would look like:
[1.234, “e”, “Error: command not found\n”]
Scenarios that this would enabled include analysis of script failures and analysis of user errors in a recorded session.
An alternative suggestion would be to add an explicit requirement to the file format specification that says that implementers MUST ignore well-formed records that include unrecognized record types.
Thank you for taking the time to consider my proposal.
I see where you’re coming from and what you’re trying to achieve. It crossed my mind once or twice to capture the split stream (o + e) but it went nowhere since I didn’t have a use case for this and nobody ever asked for that either. The way you implemented stderr capture is interesting, haven’t though of that!
Anyway, given it’s rather uncommon use case I’m hesitant to implement this in asciinema 3.0 (and v3 format). It is cool idea, and I’m sure very useful for you, but I’m trying to keep the project simple and include features that benefit more than an individual or two. I hope you understand.
Another thing about this is: stderr is typically part of visible output, and if we saved it as “e”, and the player / other tooling ignored it then the resulting display would either a) just miss stderr messages, b) become broken / garbled due to following stdout / cursor position mismatch.
With a) it’s not the end of the world, but the replay would be incomplete. With b) the replay could potentially put garbage on the screen.
In order for this to work well the player and other tools would actually need to understand “e” and properly handle it. In other words it would require full ecosystem support.
However, you’re welcome to use your custom recorder and place “e” events in v3 files. As docs for v3 say:
A tool which interprets the event stream (a player or a post-processor) should ignore (or pass through) event with codes it doesn't understand or doesn't care about.
The only thing we don’t have is the use of word “MUST”
