-
Notifications
You must be signed in to change notification settings - Fork 7.3k
Minimal execSync API Proposal #5358
Comments
cc: @piscisaureus @bmeck |
If we keep with the back-tick or |
So unless I'm understanding incorrectly it seems that the only time this would throw would be on improper argument format. Any other errors by the OS would be returned through the function. Is this correct? |
It would throw if the fork or exec failed. Basically, the cases where the spawned child process would |
ok. then otherwise you're suggesting every return basically comes in the general format of |
First of all, I don't know the history of I recently wanted to have a promise-based variant on In faithful-exec I let the result if successful be an object with I think there's something to be said for the simplicity of only returning stdout, but writing In any case, I think it's very handy to always have access to I kind of like the idea of not considering a non-zero exit code as an error. It's somewhat similar to what most would expect from a (low-level) http library: Error should only happen in case something goes wrong on the wire, not if response to the request happened to be 5xx or 4xx or so. Having a function fail in these cases is more suitable for a higher level abstraction. However, it wouldn't be that consistent with current exec behavior. I like that - at least most of the time - there's a quite obvious mapping between how |
@meryn Well, to keep it simple, we can't reasonably return both stdout and stderr separately, since that requires a separate event loop, etc, so that we can poll on both file descriptors. We should just pass 2 as the stderr fd, and collect the output from stdout, like the ``` operator does in PHP and bash. |
The tricky thing then is getting the exit code. In bash/sh, you have to access that via the |
I'm not sure what you mean by this. What are the implications of this? I can somewhat understand that people would like to have an easy way to do "shell scripting" with Node, but I do wonder if Assuming a different module, this module could function quite differently from others. Aside from an |
PHP has following api: |
Please, please don't draw inspiration from PHP. |
Drawing inspiration from php is not so bad. We do a lot, and I think is actually fine, if it's done responsibly -- the opposite of stupid is not smart, and like most platforms, PHP has a lot of good ideas buried in the muck. Certainly, backtick operators are a really nice way to do execSync. I spent a lot of years writing PHP professionally (from php 3.something through php 5.2) so I feel somewhat qualified to evaluate its good parts and bad parts :) However, even if we wanted to borrow php's exec function, we can't pass ints byref in javascript, and mutating array arguments is kind of just an oddball thing to do in JS, so that isn't really an option.
It would mean that the stderr of the child goes to the parent's stderr. (Ie, like |
All the good parts were taken from languages that use them better. Backticks for example from bash and perl. |
To me, this all seems really high-level. Useful, but high-level. I think it would be better to aim for a low-level @isaacs, I suggested returning both stdout and stderr separately, but you said
Is this "hard" in terms of how long it takes too write, or is it something that may never land in Node, because it adds too much complexity for too little benefit? If it's the former, I'd be interested in at least researching it to see how much sense I can make of it. I think I stumbled upon something interesting here. Note that I don't have any experience with Node internals, or "uv" or so. This is plain curiosity on my side. If it's the latter, I can understand the motivation behind making execSync an oddball much more. It's more or less forced by implementation details. In a discussion thread about capturing stderr output in PHP, I saw a remark about redirecting a program's stderr output to a plain file first, then reading that after the program has finished. Could that be done internally by Node, or would you consider that to be too much of a kludge (or brittle?)? |
I think that if there was an |
Of note:
@piscisaureus Thanks for making |
I haven't had a chance to look at the code well. What happens if I "cat /dev/zero"? |
Thank you very much for making |
A few people have done a few passes at implementing execSync in such a way as to get maximum feature parity with
child_process.spawn()
, while being synchronous. However, this is rather challenging, since it requires a lot of complexity to separate out stdio data, etc.I think that this is mostly unnecessary, and despite admirable efforts, has proven very challenging, and what most people really want is just something like the back-tick operator from PHP or Bash. So, here's a radically simplified proposal:
Normally, this should return just the stdout results. If the user wants to get stderr as well, or the status code, perhaps an optional argument could cause it merge stderr and stdout together, or return an object
{output:String, code:Integer}
.The text was updated successfully, but these errors were encountered: