starred/asciinema

Fork 0

mirror of https://github.com/asciinema/asciinema.git synced 2026-04-26 00:15:56 +03:00

SHELL = null fail to load #970

New issue

Closed

opened 2026-03-15 11:10:55 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 11:10:55 +03:00

Owner

Originally created by @chris-morgan on GitHub (Oct 18, 2025).
Original GitHub issue: https://github.com/asciinema/asciinema/issues/701

Pre-submission checks

I have searched existing issues and this bug has not been reported yet
This is a bug report for asciinema CLI (not player or server)

Bug Description

At least one real-world asciicast-v1 file (https://asciinema.org/a/147512.cast) has ended up with a null that asciinema now baulks at:

{
  "version": 1,
  …,
  "env": {
    "TERM": "xterm-256color",
    "SHELL": null
  },
  …
}

If you either remove the SHELL property or give it a string value, asciinema accepts it.

This occurs in asciicast-v2 files too (e.g. https://asciinema.org/a/467770.cast).

Steps to Reproduce

$ asciinema play https://asciinema.org/a/147512.cast
::: Replaying session from https://asciinema.org/a/147512.cast
Error: can't open /tmp/.tmp3VteHt: not a v1, v2, v3 asciicast file

Expected Behavior

If the tool generated such files in the past (and I presume it did), then it should parse them now.

Operating System

Arch Linux

asciinema CLI Version

3.0.0

Installation Method

Package manager (apt, yum, brew, etc.)

Terminal Information

No response

Additional Context

No response

Originally created by @chris-morgan on GitHub (Oct 18, 2025). Original GitHub issue: https://github.com/asciinema/asciinema/issues/701 ### Pre-submission checks - [x] I have searched existing issues and this bug has not been reported yet - [x] This is a bug report for asciinema CLI (not player or server) ### Bug Description At least one real-world asciicast-v1 file (https://asciinema.org/a/147512.cast) has ended up with a `null` that asciinema now baulks at: ```json { "version": 1, …, "env": { "TERM": "xterm-256color", "SHELL": null }, … } ``` If you either remove the `SHELL` property or give it a string value, asciinema accepts it. This occurs in asciicast-v2 files too (e.g. https://asciinema.org/a/467770.cast). ### Steps to Reproduce ```console $ asciinema play https://asciinema.org/a/147512.cast ::: Replaying session from https://asciinema.org/a/147512.cast Error: can't open /tmp/.tmp3VteHt: not a v1, v2, v3 asciicast file ``` ### Expected Behavior If the tool generated such files in the past (and I presume it did), then it should parse them now. ### Operating System Arch Linux ### asciinema CLI Version 3.0.0 ### Installation Method Package manager (apt, yum, brew, etc.) ### Terminal Information _No response_ ### Additional Context _No response_

kerem closed this issue

2026-03-15 11:11:00 +03:00

kerem commented

2026-03-15 11:11:06 +03:00

Author

Owner

@chris-morgan commented on GitHub (Oct 18, 2025):

This came from my examination of the 1400 most popular and 1400 most recent casts from asciinema.org, as I was trying to normalise them to asciicast-v3 to do my own (out-of-crate) experiments.

17 fail to load with this cause (that /env/SHELL is null): 147512, 204636, 206650, 257298, 304683, 376826, 407357, 407361, 407362, 407365, 407369, 407432, 407439, 420126, 420129, 431605, 467770.

I also found another 12 that fail to load because /theme is {}, and again removing the value makes it work: 239566, 239577, 263031, 304984, 333393, 347570, 407280, 614149, 651510, 724126, 740537, 745616. (Observe that the most recent of these are from the last month.) I can file a separate issue for that, but since it’s probably the same basic problem I’ll just leave it here for now.

These are the only 29 that failed to load; the rest succeeded.

@chris-morgan commented on GitHub (Oct 18, 2025): This came from my examination of the 1400 most popular and 1400 most recent casts from asciinema.org, as I was trying to normalise them to asciicast-v3 to do my own (out-of-crate) experiments. 17 fail to load with this cause (that `/env/SHELL` is `null`): 147512, 204636, 206650, 257298, 304683, 376826, 407357, 407361, 407362, 407365, 407369, 407432, 407439, 420126, 420129, 431605, 467770. I also found another 12 that fail to load because `/theme` is `{}`, and again removing the value makes it work: 239566, 239577, 263031, 304984, 333393, 347570, 407280, 614149, 651510, 724126, 740537, 745616. (Observe that the most recent of these are from the last month.) I can file a separate issue for that, but since it’s probably the same basic problem I’ll just leave it here for now. These are the only 29 that failed to load; the rest succeeded.

kerem commented

2026-03-15 11:11:11 +03:00

Author

Owner

@ku1ik commented on GitHub (Oct 20, 2025):

Thanks Chris. I noticed that as well a couple of days ago. It seems older versions of the CLI didn't filter out null/empty values when saving. The parser in 3.0 is definitely less forgiving, we may need to relax it for backward compat.

@ku1ik commented on GitHub (Oct 20, 2025): Thanks Chris. I noticed that as well a couple of days ago. It seems older versions of the CLI didn't filter out null/empty values when saving. The parser in 3.0 is definitely less forgiving, we may need to relax it for backward compat.

kerem commented

2026-03-15 11:11:16 +03:00

Author

Owner

@ku1ik commented on GitHub (Oct 23, 2025):

I looked into this a bit.

The null values inside env - this was indeed a result of asciinema CLI 2.x dumping them in the file. CLI 3.0 doesn't save nulls. I just made a fix which makes the new CLI read those files fine: 37153a6740

Regarding the {} value for a theme - asciinema CLI 2.x never saved the theme field in the file, since it didn't implement any method of theme capture (even though the field was in the asciicast v2 spec). The files you found were likely produced by another software, as they also use higher timestamp precision than asciinema ever used. The new CLI 3.0 doesn't save empty {} either. Those files were accepted by asciinema server, while they shouldn't have been... Of course one could argue that in this case {} is not really different in meaning then the absence of a theme key...

@ku1ik commented on GitHub (Oct 23, 2025): I looked into this a bit. The `null` values inside `env` - this was indeed a result of asciinema CLI 2.x dumping them in the file. CLI 3.0 doesn't save nulls. I just made a fix which makes the new CLI read those files fine: 37153a674056653fd625d2cf28f77557c39122a1 Regarding the `{}` value for a theme - asciinema CLI 2.x never saved the `theme` field in the file, since it didn't implement any method of theme capture (even though the field was in the asciicast v2 spec). The files you found were likely produced by another software, as they also use higher timestamp precision than asciinema ever used. The new CLI 3.0 doesn't save empty `{}` either. Those files were accepted by asciinema server, while they shouldn't have been... Of course one could argue that in this case `{}` is not really different in meaning then the absence of a `theme` key...