Reduce number of formats and/or do better guessing about what format user meant to use.

The format you want is:

dr pml --format=csv-list --fields=package,name,type

The format 'csv' is always a single-dimensional list of elements; 'csv-list' is a list of records, with the fields of each record being separated by a comma.

There are a number of format pairs where the single-dimensional variant has a corresponding list-of-records format (e.g. 'ini' and 'ini-sections'). I have considered some ways where Drush might autodetect situations where the user says "csv" but "means" "csv-list", and then automatically "promote" the request to the more logical, richer data type. However, there are some existing cases from Drush 5 where the pipe format devolves to the one-dimensional data format; to support that, I automatically convert two-dimensional records down to one-dimensional lists containing just the record keys, which is what you are seeing.

If we loosen up on backwards compatibility a bit, and/or implement dr pml --pipe slightly differently, then things might be able to get a little bit better in the average cases.

I agree that csv-list et. al. are terrible, at least in name. It is, however, necessary to differentiate between csv and csv-list formatters, at least at the plugin level. This is because the data structure that csv-list takes is quite different than what csv needs.

I would suggest renaming 'cvs-list' to 'csv', and give the old 'csv' some other name (no suggestion at the moment). If the user passes a data structure that only works with the primitive comma-separated value data structure to the list of csv formatters, it could detect that fact and revert to using the primitive formatter instead of using the list. It might be necessary to put a function callback name into the list of csv formatter that names the function to detect that formatter simplification is needed, as the algorithm for csv-list -> csv is perhaps different than what is needed for ini-sections -> ini.

Postponed #1993796: Various issues noticed with outputformats until we are done here.

What we discussed:

1. Remove or hide 'csv' and 'ini' formats. I think you can just delete 'csv', but you'll need to keep the other csv-like formats ('nested-csv' and 'csv-or-string'), as these are used by csv-list.

2. Rename 'csv-list' to 'csv'. Just before foreach ($input as $label => $data) { in list.inc, you are going to want to detect data like array('a', 'b', 'c') and turn it into array(array('a', 'b', 'c')).

3. Rename 'ini-sections' to 'ini', and do the same operation as #2 when an 'ini' data structure is passed to ini-sections. Detecting simple csv arrays is as easy as checking to see if the first element is -not- an array; testing ini vs ini-sections may be more involved. You'll probably need to add the name of a fn to do this detection, as suggested in #5.

4. Just get rid of key-value and key-value-list everywhere they appear, and replace them with tables. This is what we discussed, but I'm not sure how well this will work in practice. The data structure for a table is an array of rows, each of which is an array of key:value pairs, with the keys corresponding with the column ids. A key-value-list, on the other hand, is an array of key-value sections, with each of these containing a label:value pair. The big difference between key-value-list / key-value vs. a table is that the "columns" are laid out horizontally in a table, whereas they are laid out vertically in key-value lists. It would not work to just rotate the drush status or pm-info output, and have the status values laid out horizontally; you'd quickly run out of horizontal space in the terminal window. One thing that might work here would be to make Drush automatically pivot table data into the vertical format whenever the column widths got too narrow. The affect of that is that if you typed 'drush status', and for some reason it only returned a couple of values, they would be rendered side-by-side instead of on separate lines (this would never happen in practice for the status command). Also, if you ran drush pm-updatestatus in a very narrow terminal, then the projects to be upgraded would print out one after another, like drush pm-info a b c d (pmi with multiple modules). I think this could work; it would get rid of key-value-list and key-value, and would pretty much just do the right thing for the user. Rather than rotating the data structures, it might be easier to keep but hide the key-value formats, and automatically switch to those formatters when there are too many columns.

Don't know that I will have time to look at this soon. I think I know what is going on with the infinite loop. I thought that csv was not being used as a subformat (that only 'nested-csv' and 'csv-or-string' are), but it looks like it is. The reference to 'csv' as a subformat needs to be changed to something else ('csv-internal-use-only'?). Maybe 'csv-or-string' calls through to 'csv' if the input is not a string.

If I don't weigh in here in a couple of weeks, please bump the issue. I'll try to remember to check on my assigned issues.

A bit late, but I for one will miss the ini-sections output, as it is in my opinion the best balance between human readability and machine parsability. And I was already using it for such in one of my scripts, yes a --pipe implementation, but I can probably rework that to use json instead.

We could add ini output to drush_extras, perhaps. Patches welcome.