Changelog
Version 5.0.0 (2024-03-19)
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:
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:
io_uring
enabled in future versions of Node.js anyway. (Hopefully with the bug fixed by then!)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.