Option validation skipped for --backend requests

The reason that option verification is skipped here is that it would cause problems to attempt to validate the cli options when programaticly invoking a function, as existing code often unions together multiple unrelated options when calling subcommands.

drush @remote foo could remotely do cli option verification, though; the "don't validate me" net was cast too wide. I'll find a good way to insure that existing programitic calls remain unvalidated when we add validation to user-initiated remote calls.

So busy now, can't do a patch, but I can review. Sounds like a good idea.

There are two minor problems here.

1. If the user defines an arbitrary option in a path alias, it is passed on as an option for all commands.

Example:

$aliases['live'] = array (
  'project-type' => 'live',
  'parent' => '@server',
  'root' => '/srv/www/mysite/htdocs',
  'uri' => 'http://mysite.org',
);

In this instance, drush will pass --project-type=live to all remote commands, causing them to fail.

Workaround: rename 'project-type' to '#project-type', or add 'strict' => 0 to any alias that uses this feature.

The advantage of this feature is that it allows you to pass an option to a remote machine that might be tested in a custom drush command init hook. I don't use this feature, and perhaps we could remove it (or just document the workarounds). Another option would be to create a new global option that could be used by backend invoke to list the "extra" options (e.g. added in aliases), so that they could be ignored on the other end. It might be hard to figure out which options to ignore; perhaps listing all of the options that came from the command line would be easier. If this option list existed, then only options thus named would be tested for validity.

2. The dump-dir path alias is also passed along as an option to remote commands.

Example:

$aliases['live'] = array (
  'parent' => '@server',
  'root' => '/srv/www/mysite/htdocs',
  'uri' => 'http://mysite.org',
  'path-aliases' => array(
    '%dump-dir' => '/var/sql-dump/',
  ),
);

Only 'dump-dir' is passed along; 'dump2-dir' or 'dump-dir2' or most any other path alias is not passed along as an option. Seems this behavior might have something to do with sql-sync, but I don't remember why this is happening, and did not find the responsible code after a cursory examination.

The workaround is to define 'strict' => 0 in any alias that defines the dump-dir.

Hmm, this has broken Aegir, since we do a lot of backend calls and we usually use '--invoke' for that. I'll investigate whether switching to '--strict=0' will fix it for us.

It looks like a pretty simple fix to Provision: #2038891: Switch from '--invoke' to '--strict=0' for backend calls

It seems to me that adding 'invoke' as Aegir has been doing shouldn't have been necessary, as Drush-5.x adds 'invoke' for all calls that go through backend invoke, I believe. Similarly, with the current code, we could add 'strict' => FALSE for all calls that go through backend invoke except for those that pass through drush_do_command_redispatch(), which is what drush_preflight_command_dispatch() uses when the user specifies a remote command via drush @remote command.

Maybe there is value to "syntax checking" invoked command options, though.

I'm encountering the dump-dir problem.

With an alias that looks like:

$aliases['stage'] = array(
  'root' => '/path/to/drupal'
  'uri' => 'https://example.com',
  'path-aliases' => array(
    '%dump-dir' => '/home/myuser/dumps',
  ),
  'remote-host' => 'example-server',
  'remote-user' => 'example-user',
);

The following command: drush @example.stage pml returns:

Unknown option: --dump-dir. See `drush help pm-list` for available [error]
options. To suppress this error, add the option --strict=0.

I've got a fix; testing it against the test suite now.

Fixed in be9802e.

If entirely removing the alias-context options is too big of a change, there are two alternatives to consider:

1. Scan through the alias-context options, and include only those that are Drush global options.

2. Scan through the alias-context options, and add --strict=0 if any are found that are not Drush global options.

Without one of these changes, going back to including the alias-context options would not work, as you would run into the "option not recognized" problem nearly invariantly. We shouldn't require the user to know to insert 'strict' =>TRUE into an alias just because some other option is defined there.

The checked-in code is actually still broken for sql-sync; the addition of a user-defined option in a site alias will break sql-sync's use of sql-conf, preventing sql-sync from determining the site's database record.

Since the checked-in code was broken, I committed bbf2463 to changes Drush so that it will only propagate option values from site aliases if they are global options (or inside command-specific records, as usual).

I didn't think that #16.2 was a good idea; that would essentially change the rule to "always do option checking, unless you have an option that does not check out". Re-open if you think that a user-defined top-level alias option such as 'foo' => 'bar' should be passed on the command line as --foo=bar in backend invoke calls, either in some or all instances.