run-pty - npm Package Versions

Breaking change: The microsoft/node-pty dependency has been replaced by the fork @lydell/node-pty, which has prebuilt binaries. This means that a C++ compiler and Python is no longer needed to install run-pty. No C++ compilation is done on install, and you don’t need to rebuild when switching Node.js versions. On the other hand, run-pty now only works on the platforms it has prebuilt binaries for:

• macOS x86_64
• macOS ARM64
• Linux x86_64
• Windows x86_64
• Windows ARM64

If you use some other platform, please help with setting up builds for your platform over at @lydell/node-pty!

Workaround: Node.js has started work towards using io_uring on Linux, which is supposed to improve performance, but unfortunately causes a bug in the underlying node-pty library, which can cause commands to exit unexpectedly (due a signal), or can cause 100 % CPU usage. run-pty now disables io_uring, by setting the UV_USE_IO_URING environment variable to 0. (You can still set UV_USE_IO_URING=1 yourself to force io_uring.) Note that:

• That environment variable is implemented by a dependency of Node.js and may be removed in future versions of Node.js. They provide no stability guarantees for the behavior of this environment variable. This means that even with the workaround added by run-pty, you might get io_uring enabled in future versions of Node.js anyway. (Hopefully with the bug fixed by then!)
• Node.js 20.11.1 and 21.6.2 disabled io_uring by default due to a security issue (making the workaround less important for now).

Changed: When a command is killed by a signal, run-pty receives exit code 0 and then the signal number. run-pty used to ignore the signal number and exit with code 0. Now, run-pty follows the shell convention of exiting with 128 plus the signal number. You might notice this when using <kbd>ctrl+c</kbd> to exit commands: Now they might show “exit 130”, which is 128+2, where 2 is the SIGINT signal which usually means exit by ctrl+c. (Fun fact: run-pty already supported showing exit code 130 with ⚪️ instead of 🔴, so that exiting a command doesn’t look so much as an error). This is useful for example if a command goes out of memory. The operating system then kills it with signal 9, SIGKILL, which now results in exit code 128+9=137 instead of 0, which is good since the command wasn’t successful. It’s also useful in the above io_uring case: Previously the io_uring bug could cause commands to unexpectedly exit with code 0 (successful); now they would exit with 128 plus the signal that killed them (unsuccessful), which probably results in 129.

Improved: There are now slightly better error messages for invalid JSON files.

Fixed: An edge case with “kill all”.

First, a re-cap on how run-pty works. run-pty runs commands. Commands can exit. If all commands exit (by themselves, or because you killed them each separately with <kbd>ctrl+c</kbd>), run-pty keeps running, letting you restart the commands.

When you press <kbd>ctrl+c</kbd> to kill all commands, run-pty tells every command that they should exit and sets a flag that run-pty should exit itself once all commands have exited, called attemptedKillAll. If you restart one or more commands before all commands have exited – what does that mean? Well, it probably means that you changed your mind and want to keep running run-pty.

Previously, the attemptedKillAll flag would still be set in that situation. Which means that if all commands then exit, run-pty would exit too – which is inconsistent. It should keep running and let you restart the commands.

This version resets the flag attemptedKillAll if you restart any command. In other words, it no longer counts as having attempted to kill all commands if you restart something.