how to run an external command synchronously while passing things to it on stdin? Preferably without await

[bkerin]

The docs for outputSync() say Will throw an error if stdin: "piped" is set.

So if I want to run a program and pass it some stuff on stdin am I doomed to use the async interface, and thus make my wrapper for it async, and in turn to have to remember to await whateverWrapperFunc() every time I want to use it? I really hate that because sooner or later I'm going to forget to await and get a race.

While I'm ranting about this if javascript want to add syntax support for promises why not go the whole hog and also add 'default sync callers' or something so we don't have to have double interfaces to everything or litter client code with await everywhere and get a race if we forget god

[BlackAsLight]

const child = new Deno.Command('command').spawn()

const writer = child.stdin.getWriter()
await writer.write(new TextEncoder().encode("potato\n"))
writer.releaseLock()

const [stdout, stderr] = await Promise.all([
  collect(child.stdout),
  collect(child.stderr)
])

async function collect(readable: ReadableStream<Uint8Array>): Uint8Array {
  return Uint8Array.from((await Array.fromAsync(readable)).map(x => [...x]).flat())
}

[0f-0b]

#14297 proposes to add an input option to the Command constructor.

[bkerin]

Sounds great. For the moment I'm just passing things as arguments with a low size limit asserted (because idk what the actual limit is) but of course using stdin for potentially large inputs would be much better.

[BlackAsLight]

So if I want to run a program and pass it some stuff on stdin am I doomed to use the async interface, and thus make my wrapper for it async, and in turn to have to remember to await whateverWrapperFunc() every time I want to use it? I really hate that because sooner or later I'm going to forget to await and get a race.

If you want your JavaScript code to do literally anything while the Deno command is executing you can't use an event blocking function like outputSync. JavaScript is single threaded. You need to utilise promises so JavaScript can switch between tasks of getting the output of the Deno command, pushing input in and doing literally anything else while it waits.

[bkerin]

So if I want to run a program and pass it some stuff on stdin am I doomed to use the async interface, and thus make my wrapper for it async, and in turn to have to remember to await whateverWrapperFunc() every time I want to use it? I really hate that because sooner or later I'm going to forget to await and get a race.

If you want your JavaScript code to do literally anything while the Deno command is executing you can't use an event blocking function like outputSync. JavaScript is single threaded. You need to utilise promises so JavaScript can switch between tasks of getting the output of the Deno command, pushing input in and doing literally anything else while it waits.

I know, and I don't want it to. In server context it often doesn't make any sense to want it to. It's a shame to add promise/async/await to make parallelism simple and in the process make the even simpler approach (sequential operation) significantly more error-prone. As far as I can tell node and now deno just inherited this lunatic setup from the browser which I guess is inevitable but doesn't stop me wishing it could be improved. Most funcs aren't going to be intended for both sync and async use and in any case forcing the call-time default to one or the other based on the implementation detail of whether the func itself uses async stuff is unfortunate. I realize there's a small performance penalty in making a trip through the job queue but javascript glosses over similar inefficiencies all the time, and it would anyway be documented at the function definition end.

[BlackAsLight]

What exactly don't you like about the async await syntax? It allows you to write concurrent code in a sequential manner and makes it very easy to read and follow. JavaScript's single threaded-ness also makes handling race conditions insanely easy as you at exactly what points it may switch tasks; compared to some other languages where it may switch at literally any time during execution.

It also makes perfect sense in a server context to want promises; as the only thing that needs to be promises are things that rely on contexts outside the JavaScript environment.

[bkerin]

Sure promises are great to have but forcing me to expose implementation use of them to all clients is annoying and error-prone. Comments to this explain the issues with doing something better: https://stackoverflow.com/questions/47227550/using-await-inside-non-async-function they sort of boil down to it's too hard/inefficient to implement. Given the situation iI think t's worthwhile to take the trouble to provide good synchronous API including with stdin being sent as someone mentioned above.

[BlackAsLight]

Sure promises are great to have but forcing me to expose implementation use of them to all clients is annoying and error-prone.

What do you mean by this? expose implementation? If the error you're worried about running into is having to convert a function to async and then all of the functions that call it to async, then the solution to that is really just experience. When writing functions in the future you should be able to tell if it's going to need to call some async aspect and won't ever even need to be converting past sync functions to async functions.

Comments to this explain the issues with doing something better: https://stackoverflow.com/questions/47227550/using-await-inside-non-async-function they sort of boil down to it's too hard/inefficient to implement.

Reading the accepted answer should explain why you can't await a promise in a non-async function.

Functions like Deno.readFileSync, prompt, alert, don't return promises. They do something different that pauses the execution of JavaScript.

Given the situation iI think t's worthwhile to take the trouble to provide good synchronous API including with stdin being sent as someone mentioned above.

You shouldn't use sync APIs within a server context. Users will experience random lag spikes for no apparent reason.

[bkerin]

Sure promises are great to have but forcing me to expose implementation use of them to all clients is annoying and error-prone.

What do you mean by this? expose implementation? If the error you're worried about running into is having to convert a function to async and then all of the functions that call it to async, then the solution to that is really just experience. When writing functions in the future you should be able to tell if it's going to need to call some async aspect and won't ever even need to be converting past sync functions to async functions.

No, it's just a javascript limitation. It doesn't provide a way to hide the implementation detail that a function uses async code. If you're going to have syntactic sugar for promises there's no great reason not to let people hide this, it was just too hard.

Comments to this explain the issues with doing something better: https://stackoverflow.com/questions/47227550/using-await-inside-non-async-function they sort of boil down to it's too hard/inefficient to implement.

Reading the accepted answer should explain why you can't await a promise in a non-async function.

I did read it. I get it. The comments by the answers author further address the issue which comes down to 2x code per layer.

Functions like Deno.readFileSync, prompt, alert, don't return promises. They do something different that pauses the execution of JavaScript.

Given the situation iI think t's worthwhile to take the trouble to provide good synchronous API including with stdin being sent as someone mentioned above.

You shouldn't use sync APIs within a server context. Users will experience random lag spikes for no apparent reason.

It's entirely a matter of the particular application whether this matters even slightly