drush -y @sites pm-list --pipe --status=enabled
results in:
Array
(
)
Removing --pipe from the command gives the expected results.
Run time for the command with --pipe and without is about the same, making me think the command is running correctly either way.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | pipe-with-invoke.patch | 3.24 KB | greg.1.anderson |
Comments
Comment #1
jonhattanis @sites a valid alias?
Comment #2
moshe weitzman commentedyes it is. it is a multiple value alias where each value is a subdir in the sites directory of the current root. that is, all the multi-sites in a single install.
Comment #3
greg.1.anderson commentedI thought this was a duplicate, but I couldn't find any other issue, so I guess this is the first place this is documented.
--pipe does not work correctly with any command involving a list of sites, @sites being one such example. The "execute multiple" code does not merge together the pipe output when it's done.
Comment #4
clemens.tolboomNot sure whether this is related but I get a similar result when invoking
drush @example.d6 pml --pipewhere the site is on a remote server.Invoking the same command on the server give the expected list.
Tested this with 4.5 on the server
Comment #5
clemens.tolboomDigging deeper I found that the $proc['output'] is a __string__ not json so $values is never going to be an array. Thus parsing this results in the drush_set_error flow.
Unfortunately the error is send to oblivion somehow. I guess due to the --pipe construct regarding the invoking drush.
The code from into
function drush_pm_listseems clean to me apart from the last linesThere is no backend result for $pipe ... or should it be json-ed?
Comment #6
greg.1.anderson commentedThe thing that is tricky about using --pipe with backend invoke is that --pipe mode causes drush to very quickly (in DRUSH_BOOTSTRAP_DRUSH) suppress all output via ob_start(). Beyond this one problem, drush is actually handling and propagating the pipe information correctly.
Solving this problem per #3 would actually be pretty involved, as you would have to migrate data from the backend result into drush_print_pipe, only so that it could be pulled out and printed again later. Although this may sound reasonable, there are a lot of different code paths that would have to be managed with different special-case conditionals.
This patch takes a different approach. The drush bootstrap is reorganized so that the output suppression that happens in backend and pipe modes is postponed until after remote command execution / multiple site alias execution modes are tested for. The code paths for "normal" commands and backend commands still runs all of the same bootstrap steps in the same order, although the output suppression routine is now called from a different place rather than being inlined in DRUSH_BOOTSTRAP_DRUSH. In remote command execution / multiple site alias execution modes, output suppression never happens at all.
Finally, this patch forces "interactive" mode when --pipe is specified. While this solution is not very sophisticated, it does produce the correct output, and all of the test cases still pass.
Comment #7
moshe weitzman commentedFix looks reasonable to me.
Should we add any more tests for --backend or --pipe? Even if we stub them out as TODO that would be helpful.
Comment #8
greg.1.anderson commentedCommitted to master. No tests yet, but added some notes to COVERAGE.txt about tests still needed.
Comment #9
clemens.tolboomThanks ... it works for
drush @remote.d5 pml --no-core --status=enabled[edit]remote = drush-4.5 which is great :)[/edit]I don't quite copy the
Does that mean bash script will fail to run?
Comment #10
greg.1.anderson commentedNo, that was a note on an internal implementation detail. You can ignore it. Someday, backend invoke's "interactive mode" will be rewritten; this will not affect --pipe.
Comment #11
clemens.tolboomTnx for the quick fix and replay #10