Strict option commands assume unrecognized keys from a site alias belong at the end of the command

@greg - is there a way to distinguish in an alias which options should go before the command versus after? Thats needed for strict commands like rsync.

In the example above, 'site' and 'env' are not options; they are metadata in the site alias. Drush passes all options from a site alias through to remote commands, except those that begin with a '#'; if the metadata items in the above site alias were renamed, then this wouldn't be a problem. For example:

<?php
$aliases['prod'] = array(
  'parent' => '@parent',
  '#site' => 'example',
  '#env' => 'prod',
  'uri' => 'www.example.com',
  'root' => '/var/www/html/drupal/current/docroot',
  'remote-host' => 'proddrupal1.example.com',
  'remote-user' => 'drupal_deploy',
);

If you did this, though, these options would not be passed through, which would be a problem if you wanted them available, e.g. to reference in an init hook or something like that.

For options defined in a site alias that are not named via this convention, then strict option commands such as rsync will not be able to tell if the option was intended to be passed to rsync, or if it is some other option that should be passed to Drush (and potentially just ignored). Maybe what we should do is, for strict option commands, assume that any options defined in a command-specific structure (e.g. for rsync) that is not recognized by name should be passed along as an rsync option (e.g. after the 'rsync' command), whereas options at the root level (e.g. 'prod' and 'env' in the examples above) will be presumed to not be rsync options, and will be passed along after the rsync command.

This change might break some people, but better to make a few people move a couple options into a command specific option, then to leave people who need global generic options without recourse.

I have filed a bug with Acquia about this.

Let's leave this open for a feature request to distinguish what extra data goes before and after the command. Not urgent, IMO

What do you think about the idea that top-level options in the site alias are ignored, but command-specific options are included in drush strict option commands? I haven't looked into what it would take to implement, but I presume it wouldn't be too difficult. Could try it, if it seemed the desired behavior seems right. It doesn't seem like there is ever a time when a top-level option should be included in the strict options, so perhaps this is only an improvement. I think I should try to roll a patch.

That sounds like an improvement, yes. I also had the idea to introduce a special '#strict' key and you'd nest your rsync options under that. No idea of thats better or easier to implement.

Strict has to be command specific; if there are two strict commands, then it wouldn't do to mix the options for both of them together. I'll try my hand at a patch as soon as I have time. The key is to make sure that global options like 'site' and 'env' still get applied to the appropriate alias context, in case they are accessed in an init hook, etc., but to keep them out of the list of options built when getting all of the options to pass through to the strict options command.

It turns out that 'drush rsync @a @b' already did the right thing vis-a-vis strict option commands; it was only 'drush @a rsync ...' that was lacking. Command-specific was similarly unsupported when redispatching in this way. This patch fixes both problems.

Nice. Do we need any new test coverage,? Maybe just a --simulate style assertion. Feel free to commit this when you are ready. Your call about backport as well.

Committed #11 + a test as ccd0cd9.

I am uncertain about the backport. It should be okay, but there are minor changes in behavior. For example, previously drush @remote status would run drush status on the remote machine, but now the command alias is mapped to the full command name, so drush core-status is executed instead. Other changes of option order should all be considered bug fixes -- I expect, anyway. The differences are very unlikely to affect anyone, but if they did, it would be pretty mysterious. I guess this is eligible, but I haven't firmly decided to do it, is what it comes down to.

I think we should backport this. The eligible commit is ccd0cd9. Can we cherry pick that diff or are further changes needed? The diff does apply cleanly.

Also, in your example from #13, I assume that `drush status` would get still run on the remote side if the status command did not exist on the local side. I'd rather not lose that feature.

I'll have to test #15, but I believe it still works that way. Once I confirm, I will backport.

Drush 6 no longer propagates generic site alias options to backend calls at all; only command-specific options are included on the command line.

Should we change the behavior of Drush 5 to match? This would involve cherry-picking ccd0cd9 and making minor modifications to it.

I think that would be too big a change. In fact, I'm not 100% sure that skipping generic site alias options is a good idea. I'm mulling that over. For drush5, backporting #13 makes sense.

I cherry-picked ccd0cd9, and am running the test suite on it now. The command name is passed through as-is to the remote system if it does not exist locally.

Test suite passed; committed to 7.x-5.x.