ehmicky

Should this be closed in favor for https://github.com/sindresorhus/execa/issues/617? (Also relevant: https://github.com/sindresorhus/execa/issues/616)

From the discussion at https://github.com/nodejs/node/issues/27490, it appears `childProcess.killed` just means "`childProcess.kill()` was called". Regardless of whether it terminated the process. For example `childProcess.kill(0)` sets `childProcess.killed` as `true`. The purpose of...

There is actually a difference between: - `childProcess.killed`: left as is by Execa, i.e. has the same behavior as core Node.js. It only checks whether `childProcess.kill()` has been called (even...

Sounds good. Done at #625.

Yes, it is not a bug from Node.js. Namely, the `input` option is implemented by writing to the child process `sdin` after it's been spawned. Doing so creates a timing...

I took a stab at it, but realized the following problem: `child_process.spawn()` `stdio` option only allows [streams that have an underlying file descriptor](https://nodejs.org/dist/latest-v20.x/docs/api/child_process.html#optionsstdio). > object: Share a readable or writable...

Thanks for all those different ideas! :) > It says it accepts a socket too, so you could potentially create that: > Otherwise, I don't think it's too bad to...

I took another stab at it, but encountered the following problem, which applies to both the temporary file and the socket solution: `execa()` returns the `childProcess` synchronously. `child_process.spawn()` is called...

Another potential idea: calling a second child process that just outputs the string, then pipe its `stdout` to the first child process's `stdin`. This would remove the need for filesystem/network...

I am starting to wonder whether this is something that should be fixed by Node.js core, so I opened https://github.com/nodejs/node/issues/48786 to port the `input` option from `child_process.spawnSync()` to `child_process.spawn()`.