Have child_process.exec support the input and stdio options, like execSync does

[cpcallen]

What is the problem this feature will solve?

The documentation for child_process.execSync says:

The child_process.execSync() method is generally identical to child_process.exec() with the exception that the method will not return until the child process has fully closed.

But in fact it introduces a number of extra options (input, stdio) that are for some reason not supported by exec, even though there is no obvious reason why they would not be useful there.

What is the feature you are proposing to solve the problem?

When rewriting synchronous code as asynchronous, it should be possible to replace execSync calls with exec calls (and add suitable machinery to detect child process completion), but failing to support the very common {stdio: 'inhert'} option makes this much more difficult than it should be.

There seems to be no fundamental reason why the stdio option cannot be supported, because spawn supports it while also being async.

What alternatives have you considered?

It is possible to add suitable event handlers to copy from the child process to stdout, but this is non-trivial and is not the same as inheriting stdiout (e.g. it breaks tty detection).

child_process.spawn is a usable alternative that does support {stdio: 'inherit'}, but it requires refactoring the arguments into a separate array, which is inconvenient.

[sindresorhus]

Duplicate of #25231

[cpcallen]

Duplicate of #25231

Partial duplicate only: #25231 does not mention stdio, which is actually the more interesting one (to me at least).

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[rkrisztian]

I am looking for a promise-based alternative to execSync. Right now, I can't find anything that works exactly the same way.

• For example, instead of fs.mkdirSync you can have await fs.promises.mkdir.
• But what do we have for execSync with stdio: inherit?
  • await util.promisify(exec) is no good because it does not support stdio: inherit.
  • spawn does not block, and can't await on it.

=> This ticket isn't justified in my opinion, and should be reopened.

[bnoordhuis]

See the other issue. There's no point in reopening this one because, to summarize, there's no consensus on how or if this should be added.

[rkrisztian]

@bnoordhuis, just because there's no consensus, it's still a valid problem, so I find your argument non-constructive.

Edit: Even though execa is a working alternative for my problem, it's too bad we can't rely on a native function.

[bnoordhuis]

To clarify: If it's not going to happen, it's not going to happen. No point in having open issues for something that's not going to happen.

But if you're just arguing for the sake of arguing, go away.

[rkrisztian]

I don't do pointless things. I look for solutions. You're rude. I'm trying to make you realize that sometimes it's just better to have something than nothing, otherwise history repeats itself, like it happened with Prettier: prettier/prettier#9561 . it's just crazy how things are handled in the world. I've seen several GitHub/Atlassian issues where people who needed a feature had to wait years, even regardless of how popular the request was. We can't fork everything, constant forking makes things a mess. Yet if it's a common feature it's common sense to want to have it. I believe that similarly, new technologies, libraries, and frameworks emerge every day, but more because there is no consensus on how to do things, than because of natural evolution. That is everything but practical.

Having said that, I understand that this comment probably won't change a thing. So yes, sadly but I'll move on.

[bnoordhuis]

I'm trying to make you realize that sometimes it's just better to have something than nothing

Rest assured that the people working on this project think about that a lot more than you do, random commenter from the internet peanut gallery, and sometimes the conclusion is that in fact, no, it's better to have nothing than something that's bad.

[rkrisztian]

There was never any doubt you understand the internals of your project more than I do, and that shouldn't be the debate here. I was wrong though: whether it is better or not to have something than nothing is actually a classic debate between iterative mindset and maintaining quality. Its two extremes are rash decision-making and analysis paralysis, neither of which are good for the users in long term. The middle ground is however are also well practiced on the Internet: clearly marked experimental or beta features. Maybe that idea cannot be applied exactly to this problem, or isn't worth the effort. Not for me to decide, as you said, I'm just a random commenter. Please note though that calling people one is getting a bit close to being rude again: getting personal is some form of manipulation. I don't want to be the enemy here. If I was harsh in some way then sorry. As I promised, I'm moving on.