I needed this, and it seemed generically useful enough to have in Drush core (there is a suggestion for it at #582598: Submodule names in module package need guessing). The doxygen is below.

Let me know if you have any thoughts - the main things I am not sure about are if the $final_options concept is useful (or if we should limit it to a single built in "Done" option), as well as if we should try and cover eventualities by adding a $callback parameter (this could allow callers to alter the $selections, and perhaps even $options mid-stream in the process. I am thinking this could be handy where there are dependencies of some kind implicit in the options). If I don't hear anything in the next 2 or 3 days I am planning on committing as is.

/**
 * Ask the user to select multiple items from a list.
 * This is a wrapper around drush_choice, that repeats the selection process,
 * allowing users to toggle a number of items in a list. The number of values
 * that can be constrained by both min and max: the user will only be allowed
 * finalize selection once the minimum number has been selected, and the oldest
 * selected value will "drop off" the list, if they exceed the maximum number.
 *
 * @param $options
 *   Same as drush_choice() (see above).
 * @param $defaults
 *   This can take 3 forms:
 *   - FALSE: (Default) All options are unselected by default.
 *   - TRUE: All options are selected by default.
 *   - Array of $options keys to be selected by default.
 * @param $prompt
 *   Same as drush_choice() (see above).
 * @param $label
 *   Same as drush_choice() (see above).
 * @param $mark
 *   Controls how selected values are marked.  Defaults to '!value (selected)'.
 * @param $min
 *   Constraint on minimum number of selections. Defaults to zero. When fewer
 *   options than this are selected, no final options will be available.
 * @param $max
 *   Constraint on minimum number of selections. Defaults to NULL (unlimited).
 *   If the a new selection causes this value to be exceeded, the oldest
 *   previously selected value is automatically unselected.
 * @param $final_options
 *   An array of additional options in the same format as $options.
 *   When the minimum number of selections is met, this array is merged into the
 *   array of options. If the user selects one of these values and the
 *   selection process will complete (the key for the final option is included
 *   in the return value). If this is an empty array (default), then a built in
 *   final option of "Done" will be added to the available options (in this case
 *   no additional keys are added to the return value).
 */
CommentFileSizeAuthor
drush_choice_multiple.patch4.23 KBowen barton

Comments

greg.1.anderson’s picture

I think that entering a csv list of option numbers would be more usable than mark / confirm / cancel in a loop.

See also #1007148: Make drush_choice and drush_print_file respect non-interactive modes. Overall, I think this is a good idea.

moshe weitzman’s picture

Greg's idea sounds better to me as well. Am open to discussion here.

owen barton’s picture

I agree CSV would be preferable for many kinds of choices, certainly worth adding. I think we may still sometimes need some kind of refinement/confirmation loop of the kind implemented in my patch though, especially if you have min/max constraints.

In terms of implementation, I guess the main question is if we should (a) keep the basic drush_choice_multiple in the patch, but extend drush_choice to add optional CSV processing (perhaps this could be a lightweight form of drush_choice_multiple when you don't need refinement/confirmation), (b) drop drush_choice_multiple completely, and build more functionality into drush_choice or (c) add the basic text input code (and CSV stuff) into drush_choice_multiple directly (and not build on drush_choice).

Thoughts?

greg.1.anderson’s picture

I don't think that we should put loops or min/max constraints in drush core until we need that functionality for a core command.

I'm indifferent to extending drush_choice vs. making drush_choice_multiple, so long as the former does not involve changing the function signature of drush_choice (i.e., don't change existing parameters, only add new parameters with default values). If implementing that is not clean, then make drush_choice_multiple.

moshe weitzman’s picture

I'm also indifferent about implementation. I'll just trust Owen to sort it out.

I do think loop and max/min are core worthy. Even if no core command uses them right now, they will be much appreciated in Contrib.

greg.1.anderson’s picture

I was thinking about the implementation of the loop and min/max, and think that everything could easily be inserted into drush_choice without too much code, so I agree w/ moshe.

moshe weitzman’s picture

Assigned: Unassigned » owen barton
Status: Needs review » Reviewed & tested by the community

We can commit this as is for Drush4. As along ass Owen is comfortable with it.

owen barton’s picture

Status: Reviewed & tested by the community » Needs review

I would like to add the ability to specify as CSV...I'll add that and commit.

greg.1.anderson’s picture

Status: Needs review » Reviewed & tested by the community

This can go in drush-4 any time, so long as the behavior and signature of drush_choice stays the same. csv would be nice.

owen barton’s picture

Status: Reviewed & tested by the community » Postponed

Committed as is for now, leaving as postponed so to help us remember to add CSV later on

greg.1.anderson’s picture

Title: Add drush_choice_multiple to allow multiple interactive selections » Add the ability to enter a csv list of items to drush_choice_multiple
Status: Postponed » Active

I think that "active" is a better status for now.

drzraf’s picture

see #1007578: Add the ability to enter a csv list of items to drush_choice_multiple about the ability to select All/None which is not far from what is requested here.

greg.1.anderson’s picture

Version: » 8.x-6.x-dev
Status: Active » Closed (won't fix)
Issue tags: +Needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.