Add a spawn method for logging stdout and stderr.

[chasingmaxwell]

This adds the spawn method so the stdout and stderr streams can be logged directly rather than being returned in a buffer. Example usage: drush.spawn(['cc', 'drush']);

[chasingmaxwell]

I just realized drush_test.js and the readme should both be adjusted. Don't really have time for that tonight though :\

[chasingmaxwell]

I was thinking about how to adjust the readme and I started wondering if, instead of having two commands, perhaps spawn should be used for the main exec command. Then whether or not output is logged during the command execution could be controlled by an option. What are your thoughts @elliotttf?

[elliotttf]

If this is a result of jshint stuff can you set node option in .jshintrc?

[chasingmaxwell]

Hm, looks like the node option was already set. Might have been a hiccup in my syntastic config because I was seeing errors in vim and now I'm not. I'll remove it.

[elliotttf]

instead of having two commands, perhaps spawn should be used for the main exec command

I like the sound of that. Anything to reduce code repetition and increase simplicity is good by me!

Nice job on this. Admittedly it's been a loooong time since I've looked at the code so my comments above might be way off base. As long as the existing functionality isn't broken by this I'm happy to merge when you're ready.

[chasingmaxwell]

I like the sound of that. Anything to reduce code repetition and increase simplicity is good by me!

Okay, I think I'll try to do that. There really isn't a reason I can tell that the two should be separate other than whether or not the output is logged automatically.

[chasingmaxwell]

@elliotttf this is ready to go again. Drush.exec() now uses spawn instead of exec, but it still returns a promise for the output of the drush command. There was no longer any need for the maxBuffer option, but I added a log option to allow the logging of stdout and stderr on the spawned processes.

[patrickocoffeyo]

@chasingmaxwell I've also looked over the code, and it looks pretty great. @elliotttf I'll be functionally testing this soon and will report back.

[elliotttf]

s/\]//

[chasingmaxwell]

wow, how did I not catch that. Sorry!

[elliotttf]

I think this looks good. Have you tried a database sync with these changes?

[chasingmaxwell]

Have you tried a database sync with these changes?

@elliotttf I haven't tried sql-sync, but I have used the cat option to import a database with sql-cli and it worked just fine.

[elliotttf]

I'm specifically worried about the use case that drush-reloadp tackles. This was the driving force behind handling the large amount of output from the underlaying drush commands.

[chasingmaxwell]

I've been pretty swamped the last couple days. If anyone else is able to test this with drush-reloadp that would be awesome (especially so aquifer can stop pointing to my fork of drush-node). Otherwise I'll get to this in the next few days.

[elliotttf]

Yeah, looks like it's not working, specifically with the way drush-reloadp does gzipping...

nbcunbc|create-media-collection ⇒ drush-reloadp -s @nbcunbc.acc -d @nbc.local
events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: incorrect header check
    at Zlib._handle.onerror (zlib.js:366:17)

[chasingmaxwell]

Bummer. Thanks for testing it! I'll look into it.