remote confirmation breaks command

If you type "y" or "n" , then the command continues; you will be able to retroactively see the prompt.

Perhaps this could be fixed by inserting output stream flushing in drush_confirm & similar functions.

So you are just supposed to know that the delay is actually a prompt (of unknown nature) and then press Y?

No, #1 part 1 was just an observation. I think this can be fixed.

flush() does not work. ssh -t does not work. php -d implicit_flush=1 is already set in cli. Adding a newline in drush_print_promt does cause the prompt to be printed; perhaps we could do this for remote-sourced commands only, but this is not a complete solution either, as user input is not echoed until [ENTER] is pressed.

Still considering alternatives.

Correction: user input is echoed unless ssh -t is used. This allows for a fairly simple fix that gets us most of the way there: just add a newline after the prompt if the command was remotely sourced.

There may be even better solutions, but this is simple and quick and meets the basic need of allowing remote interactive commands to work correctly.

Here's a strategy that works much better, and does not require adding newlines after prompts. Might be worth refactoring into _drush_proc_open_interactive, but this should be more-or-less the right idea functionality-wise. Feedback desired.

n.b. test cases pass except for siteSshCase, which I believe is broken prior to this patch by the recent drush @site ssh change.

Would be great if msonnabaum looked this over, as he has been working on the concurrent commands patch.

#6 is working, but not as expected. When $descriptors[0] is set to STDIN, then the output from the subshell is written directly to STDOUT (and standard error goes directly to STDERR), and nothing appears on $pipes[1]. I tried to recode it such that the I/O loop is reading output from $pipes[1], and manually checking for input on STDIN and writing it to $pipes[1] as it appears, but I could not get the reading from $pipes[1] to be non-blocking. Maybe some additional googling about php proc_open will help here.

In the short term, we could just recode a separate _drush_proc_open_interactive routine; the value of manually parsing I/O on interactive subshells is minimal (although it would allow us to add output labels on interactive subcommands run on multiple site aliases, the value of that is more novel than practical).

Here is another patch that works every bit as well, but is much simpler (and more correct). I recommend this approach.

Looks fine to me.

Committed 38f4be1, a variant of #9 that uses the new proc_open wrapper.