The 'options' array for newer commands, like drupal-directory and site-install, list their options without a preceding "--", whereas older commands such as help do.

For example:

  $items['help'] = array(
    'description' => 'Print this help message. See `drush help help` for more options.',
    'bootstrap' => DRUSH_BOOTSTRAP_DRUSH, // No bootstrap.
    'options' => array(
      '--sort' => 'Sort commands in alphabetical order. drush waits for full bootstrap before printing any commands when this option is used.',
      '--filter' => 'Restrict command list to those commands defined in the specified file.',
      '--html' => 'Print help for all commands in HTML format.',
      '--pipe' => 'A list of available commands, one per line.',
    ),

... and:

  $items['site-install'] = array(
    'description' => 'Install Drupal along with modules/themes/configuration using the specified install profile.',
    'arguments' => array(
      'profile' => 'the install profile you wish to run. defaults to \'default\'',
    ),
    'options' => array(
      'db-url' => 'A Drupal 5/6 style database URL. Only required for initial install - not re-install.',
      'db-prefix' => 'An optional table prefix to use for initial install.',
      'account-name' => 'uid1 name. defaults to admin',
      'account-pass' => 'uid1 pass. defaults to admin',
      'account-mail' => 'uid1 email. defaults to admin@example.com',
      'locale' => 'A short language code. Sets the default site language. Language files must already be present. You may use download command to get them.',
      'clean-url'=> 'Defaults to 1',
      'site-name' => 'Defaults to Site-Install',
      'site-mail' => 'From: for system mailings. Defaults to admin@example.com',
      'sites-subdir' => "Name of directory under 'sites' which should be created. Only needed when the subdirectory does not already exist. Defaults to 'default'",
    ),

Seems this should be standardized one way or the other. I would tend to think that the newer way, without the "--", is better. If you like the way that 'help' renders it better with the "--", then maybe help could automatically prepend -- to each help item?

Options could also be exploded on "," and prepended with just a "-" if the option was but a single character. This would be a good first step toward #996092: Better handling of unknown option. Alternately, we could leave the global options as they are.

At a minimum, though, the options should be standardized one way or the other.

Comments

moshe weitzman’s picture

Good question. I've been wondering myself.

I think command definition should definately not include those dashes. I do think they provide enough value when presented in help command that we should prepend a single or double dash as you describe.

I'm open to doing this standardization work before release if you think you could get to it. Otherwise, no problem to defer to Drush5.

greg.1.anderson’s picture

Assigned: Unassigned » greg.1.anderson

Yes, I'll try to do this, time permitting.

greg.1.anderson’s picture

Title: Should command options begin with -- or should they not? » Unify command help so that help options do not begin with "--" in command help.
Status: Active » Fixed

Committed: http://drupal.org/cvs?commit=473122

I figured that the diffs on this were too long for anyone to want to review line-by-line; since this only affects help output, I went ahead and committed. Please re-open if any issues come up.

I removed most of the '--' prefixes in help options via sed -i -e "s|\(^ *'\)--|\1|" `find -exec grep -l "^ *'--" {} \;`, and used cvs diff to verify that there were no spurious replacements. There were a few other items that I had to find and fix by hand.

There was a bit of code required to put the '--' back in during help display, and a bit more code to handle global options in help, help --html and drush topic.

The improved structure will help with #996092: Better handling of unknown option and #735338: Improved help in drush-5. The current code does not double-add the '--' if it already exists in a help option, but it does log a debug message when one of these is encountered. If we strongly wanted to get people to fix their command records, we could turn this into a warning.

moshe weitzman’s picture

Thanks Greg. I think #996092: Better handling of unknown option should turn this debug into a warning. That way, the warning starts when it matters.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.