in 7.x-5.x land, drush up --pipe would return output like this:
backup_migrate 7.x-2.4 7.x-2.5 Update-available
drupal 7.20 7.22 Update-available
colorbox 7.x-2.0 7.x-2.4 Update-available
ctools 7.x-1.2 7.x-1.3 SECURITY-UPDATE-available
email_registration 7.x-1.0 7.x-1.1 Update-available
entity 7.x-1.0-rc3 7.x-1.0 Update-available
entityreference_prepopulate 7.x-1.1 7.x-1.3 Update-available
formblock 7.x-1.x-dev 7.x-1.x-dev Update-available
libraries 7.x-2.0 7.x-2.1 Update-available
link 7.x-1.0 7.x-1.1 Update-available
linkit 7.x-2.5 7.x-2.6 Update-available
quiz 7.x-4.0-alpha10 7.x-4.0-beta1 Update-available
migrate 7.x-2.4 7.x-2.5 Update-available
og 7.x-2.0-beta4 7.x-2.2 Update-available
realname 7.x-1.0 7.x-1.1 Update-available
token 7.x-1.4 7.x-1.5 Update-available
uuid_features 7.x-1.0-alpha1+3-dev 7.x-1.0-alpha3 Update-available
views 7.x-3.5 7.x-3.7 SECURITY-UPDATE-available
views_bulk_operations 7.x-3.0 7.x-3.1 Update-available
workflow 7.x-1.0+20-dev 7.x-1.1 Update-available
due to this code:
// Pipe preparation.
if (drush_get_context('DRUSH_PIPE')) {
$pipe = "";
foreach($updateable as $project) {
$pipe .= $project['name']. " ";
$pipe .= $project['existing_version']. " ";
$pipe .= $project['candidate_version']. " ";
$pipe .= str_replace(' ', '-', pm_update_filter($project)). "\n";
}
However, with the outputformats revamp, awesome as they are, running the same command results in this:
backup_migrate
drupal
colorbox
ctools
email_registration
entity
entityreference_prepopulate
formblock
libraries
link
linkit
quiz
migrate
og
realname
token
uuid_features
views
views_bulk_operations
workflow
with no newline at the end, so my next command-line is whacked.
However, the main issue is that drush up --help still says
--pipe Returns a whitespace delimited list of projects with any of its extensions enabled and their respective
version and update information, one project per line. Order: project name, current version, recommended
version, update status.
Initially I thought this should be corrected to use the older whitespace-delimited format, but after poking around with the code I found that while pm-update doesn't allow for formats, the new pm-updatestatus does. This should be corrected to direct the user to consult the help for pm-updatestatus, or just use pm-updatestatus --format=csv-list to get similar information in a similar format, since drush up --pipe now simply runs pm-updatestatus in DRUSH_PIPE mode (as of commit 9c4ef70d46d8b308644db57e158b04cae5d87292: "Issue #1912628 (part 17): Factor pm-updatestatus command out of pm-updatecode and convert it to use outputformat engine." Found via git bisect.).
function drush_pm_updatecode() {
// In --pipe mode, just run pm-updatestatus and exit.
if (drush_get_context('DRUSH_PIPE')) {
drush_set_option('strict', 0);
return drush_invoke('pm-updatestatus');
}
using pm-updatestatus --format=csv-list | head:
Achievements (achievements),7.x-1.5,7.x-1.5,Up to date
Backup and Migrate (backup_migrate),7.x-2.4,7.x-2.5,Update available
Drupal,7.20,7.22,Update available
Boxes (boxes),7.x-1.1,7.x-1.1,Up to date
CAPTCHA (captcha),7.x-1.0-beta2+16-dev,7.x-1.x-dev,Up to date
Colorbox (colorbox),7.x-2.0,7.x-2.4,Update available
Context (context),7.x-3.0-beta6,7.x-3.0-beta6,Up to date
Context OG (context_og),7.x-2.1,7.x-2.1,Up to date
Chaos tools (ctools),7.x-1.2,7.x-1.3,SECURITY UPDATE available
Devel (devel),7.x-1.3,7.x-1.3,Up to date
That said, I'm looking forward to using the output format engines such as csv-list and ini-sections for easy parsing of drush output in the future!
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | drush-.x-.x-pm-update--1980834-4.patch | 12.25 KB | greg.1.anderson |
| #4 | interdiff.txt | 4.14 KB | greg.1.anderson |
| #3 | drush-.x-.x-pm-update--1980834-3.patch | 10.29 KB | greg.1.anderson |
Comments
Comment #1
moshe weitzman commentedI'm leaning toward simply removing --pipe from pm-updatecode and instruct people to use pm-updatestatus. Backward compat be damned.
I notice that the first column in has changed to 'Friendly name (machine_name)'. Seems like we would prefer just machine_name there.
Comment #2
greg.1.anderson commentedFirst off, I changed --pipe to just list the modules that needed updating for consistency, and because it seemed most useful. --pipe is supposed to output the format most useful for use in scripts, and it seems to me that 'iterate over the items that need updating' is the most useful thing to print in --pipe mode. This can easily be changed if folks disagree.
To get output similar to 7.x-5.x, use this:
Important: That doesn't quite work in 6.x-beta1. Patch is coming shortly that allows this (tests running on the new code right now).
The reason that the first column is now the label instead of the name is that currently, the output format engine does not have a feature that allows the default field list to vary by the selected output type. If you think it should do that, I could add that feature; as it is, though, 'label' is what is shown in the normal table output, so it is also shown in cvs-list mode as well.
I did not remove --pipe from pm-updatecode because it did not seem necessary to do so -- but I certainly can do that as well
if you really think it should go away.
Comment #3
greg.1.anderson commentedSome tests have minor failures; will have to return to this later. Here is a progress patch.
Comment #4
greg.1.anderson commentedHere is a version that fixes up #3. Also, I realized that in addition to default fields, the output format engine also supports default "pipe" fields. I extended this concept to use the "pipe" fields whenever a "machine parsable" output format is selected (unless the user explicitly selects the fields to use). The means that we can use the human-readable label for the pm-updatestatus "table" output, and the machine name when cvs-list is used.
Comment #5
StephenBrown commentedI'm perfectly fine with the update removing --pipe from pm-updatecode, as long as there is documentation to use pm-updatestatus instead. However, I am a big fan of consistency, and if pm-update --pipe is kept, leaving it just list the modules that need updating is indeed most useful. The default comma separator also necessitates less text processing (since the status had spaces replaced with dashes in 7.x-5.x to make it truly whitespace separated)
That said, having an option for a custom list-separator is a great addition, as well as using default pipe fields. And, of course, having only the name available as a field is somewhat of a requirement for machine-parsable output. For now though, I'll continue using pm-updatestatus instead.
Thanks for the good work!
Comment #6
moshe weitzman commentedThis looks good to me. Just a minor question below and then this can be committed.
why would separator be an array?
Comment #7
greg.1.anderson commentedThanks for #6. That is residual code; the separator was coming through as an array due to a different bug that I fixed, so that conditional can be removed -- I just forgot. Let me run the unit tests on everything again with that gone just to be sure that it's okay, and then I'll commit.
(The reason that the separator was a list was that the output format code was always calling drush_get_option_list for output format options; I added a specifier that indicates whether the option should be a list or not so that drush_get_option can be called for options such as --separator, and drush_get_option_list can be called for options that are lists, such as --fields.)
Comment #8
greg.1.anderson commentedCommitted.