Dev

[paulpflug]

New version with all problems resolved 😄

[keithamus]

Cool, I guess we tried exec and that didnt work so well, so lets do detached and see how that goes.

[paulpflug]

I did deep testing on linux and windows, was quite a tinkering 😄

But before releasing I would like to wait for some positive resonance, what do you think?

[keithamus]

Sounds like a good idea. I'll try it out on a couple of projects and let you know how it goes.

[keithamus]

FYI for everyone coming here, to install this development version - run:

npm install git+ssh://github.com/keithamus/parallelshell.git#dev

If people report this as working we can merge it and cut a new version 😄

[estk]

succes is spelled success.

[keithamus]

@paulpflug I've just had some time to try this out on a project, and noticed I'm getting errors due to the stdio option. It's quite odd, but I'll show you my findings:

with stdio: ['pipe', process.stdout, process.stderr]

$ parallelshell 'echo hello' -v
parallelshell: `echo hello` failed with exit code 1
parallelshell: exit code: 1

with stdio: ['pipe', null, null] (or 'pipe' for each one)

$ parallelshell 'echo hello' -v
parallelshell: `echo hello` ended successfully
parallelshell: exit code: 0

Finally, omitting stdio and instead adding child.stdout.pipe(process.stdout); and child.stderr.pipe(process.stderr);:

$ parallelshell 'echo hello' -v
hello
parallelshell: `echo hello` ended successfully
parallelshell: exit code: 0

Obviously the last one is the most desirable, but I dont know why spawn is erroring when I just hand off the streams to the stdio option, as it's a valid option...

[estk]

I don't see any output when I run commands now. Seems this line is the culprit. Why are we detaching the process?

[keithamus]

So they can be killed properly and we don't end up with zombie processes. I actually think L122 is the culprit more than L124

[paulpflug]

If I remember correctly, the piping will not preserve color and format.
The error looks strange indeed.. But currently I have no time to
investigate, maybe in 2 weeks or so.

Am 21. September 2015 10:51:45 nachm. schrieb Keith Cirkel
[email protected]:

@paulpflug I've just had some time to try this out on a project, and
noticed I'm getting errors due to the stdio option. It's quite odd, but
I'll show you my findings:

with stdio: ['pipe', process.stdout, process.stderr]

$ parallelshell 'echo hello' -v
parallelshell: `echo hello` failed with exit code 1
parallelshell: exit code: 1

with stdio: ['pipe', null, null] (or 'pipe' for each one)

$ parallelshell 'echo hello' -v
parallelshell: `echo hello` ended successfully
parallelshell: exit code: 0

Finally, omitting stdio and instead adding
child.stdout.pipe(process.stdout); and child.stderr.pipe(process.stderr);:

$ parallelshell 'echo hello' -v
hello
parallelshell: `echo hello` ended successfully
parallelshell: exit code: 0

Obviously the last one is the most desirable, but I dont know why spawn is
erroring when I just hand off the streams to the stdio option, as it's a
valid option...

---

Reply to this email directly or view it on GitHub:
#30 (comment)

[estk]

@keithamus In the child_process manual it says:

Stream object - Share a readable or writable stream that refers to a tty, file, socket, or a pipe with the child process. The stream's underlying file descriptor is duplicated in the child process to the fd that corresponds to the index in the stdio array. Note that the stream must have an underlying descriptor (file streams do not until the 'open' event has occurred).

Maybe the process has not 'open'ed yet? Anyway I think we just want to use integers like so:

...
stdio: [ 'pipe', 1, 2 ],
...

Also, why are we opening a pipe?

[estk]

Just opened #35. This is working for me.