rsync: --php=/usr/bin/php: unknown option
rsync error: syntax or usage error (code 1) at main.c(1447) [client=3.0.9]

I didn't find any mention of this error/bug here in the issues, but I get this error on all my servers/machines running various flavors of SLES 11 and opensuse 12.1 when I run

drush core-rsync @dev @local

running in verbose indicates that the option --php=/usr/bin/php is indeed passed to rsync. I didn't have time to reverse engineer drush to figure out why, but in order to get my machines all working I made the following change.

in function drush_core_exec_rsync located in /usr/share/php5/PEAR/drush/commands/core/rsync.core.inc following this line:

  $exec = "rsync -e 'ssh $ssh_options' $options $source $destination";

add:

  $exec = preg_replace('/--php=[\/\w]+?\s/', '', $exec);

and drush will now happily rsync my drupal installations.

Comments

patcon’s picture

Whoa. What are the chances...

Am just working through trying to get a php_codesniffer integration figured out with composer, and am getting the same cryptics error: ERROR: option "--php=/usr/bin/php" not known.

phpcs then spits out it's default help text. Thought it was something to do with my hacking and not understanding what I was doing, but this is a little too coincidental :)
https://github.com/myplanetdigital/drupalcs

patcon’s picture

You should be able to reproduce the error with this and drush 5.1 (only work with PHP 5.3.x)

drush dl composer
git clone --branch=drush-command-composer https://github.com/myplanetdigital/drupalcs.git
cd drupalcs
drush composer install
drush cs
patcon’s picture

patcon’s picture

hmmm... maybe an arv conflict in my case... composer uses it
http://drupalcode.org/project/drush.git/commitdiff/a071db30cb4d0c0a8e8f3...

EDIT: nevermind. not composer-related

greg.1.anderson’s picture

Assigned: Unassigned » greg.1.anderson

Yeah, that sounds wrong all right. --php probably just needs to be declared a global option. Funny this wasn't noticed earlier.

greg.1.anderson’s picture

Status: Active » Postponed (maintainer needs more info)

'php' is already a global option; I cannot reproduce this with DRUSH_PHP=/usr/bin/php drush rsync @a @b. Did not try #2 per #4; is perhaps #2 necessary to reproduce?

patcon’s picture

Definitely a totally different way to get there, but same mystery --php flag getting tacks on somewhere it seems.

I'm on a lucid VM that's been sloppily upgraded from 5.2.10 to 5.3.x, but i'll be updating my chef recipes to provision it right to 5.3.x, so maybe it's better to control for that first.

I'll bump this in a week or so when I've had a chance

rteijeiro’s picture

Version: 7.x-5.1 » 7.x-5.2

I am getting the same info with the 5.2 version. Here you are my debug output:

root@lamp:/var/www/cvc# drush -d -v rsync @vps.cvc @lamp.cvc
Bootstrap to phase 0. [0 sec, 2.25 MB]                               [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drush() [0.01 sec, 2.39 MB] [bootstrap]
Cache HIT cid: 5.2-commandfiles-0-bf2a928d15983ee940b3e40875266b5c [0.01 sec, 2.4 MB]                                                 [debug]
Bootstrap to phase 0. [0.06 sec, 5.29 MB]                                                                                         [bootstrap]
Bootstrap to phase 0. [0.08 sec, 5.29 MB]                                                                                         [bootstrap]
Found command: core-rsync (commandfile=core) [0.08 sec, 5.29 MB]                                                                  [bootstrap]
Including /usr/share/php/drush/commands/core/rsync.core.inc [0.11 sec, 5.3 MB]                                                    [bootstrap]
Loaded alias @vps.cvc from file /root/.drush/vps.aliases.drushrc.php [0.16 sec, 5.37 MB]                                             [notice]
Loaded alias @lamp.cvc from file /root/.drush/lamp.aliases.drushrc.php [0.24 sec, 5.38 MB]                                           [notice]
You will destroy data from /var/www/cvc/ and replace with data from root@46.105.20.153:/var/www/clinicaveterinariacamas.com//
Do you really want to continue? (y/n): y
Calling system(rsync -e 'ssh -p 60022' -akzv --exclude=".git" --exclude=".gitignore" --exclude=".hg" --exclude=".hgignore" --exclude=".hgrags" --exclude=".bzr" --exclude=".bzrignore" --exclude=".bzrtags" --exclude=".svn" --exclude="settings.php" --stats --progress --php=/usr/bin/php root@46.105.20.153:/var/www/clinicaveterinariacamas.com// /var/www/cvc/);
rsync: --php=/usr/bin/php: unknown option
rsync error: syntax or usage error (code 1) at main.c(1443) [client=3.0.7]
Could not rsync from root@46.105.20.153:/var/www/clinicaveterinariacamas.com// to /var/www/cvc/ [3.08 sec, 5.48 MB]               [error]
Command dispatch complete [3.08 sec, 5.44 MB]                                                                                        [notice]
Peak memory usage was 6.51 MB [3.08 sec, 5.44 MB]                                                                                    [memory]

Hope it helps.

greg.1.anderson’s picture

What are the contents of your two alias definitions?

rteijeiro’s picture

Status: Postponed (maintainer needs more info) » Needs review

Hi. This is the content of my two alias definitions (only pasted te code of the site I am rsyncing):

LAMP

$aliases['cvc'] = array(
  'root' => '/var/www/cvc',
  'uri' => 'lamp/cvc',
  'path-aliases' => array(
    '%dump-dir' => '/tmp',
  ),
);

VPS

$aliases['cvc'] = array(
  'root' => '/var/www/clinicaveterinariacamas.com',
  'uri' => '46.105.20.153/clinicaveterinariacamas.com',
  'remote-host' => '46.105.20.153',
  'remote-user' => 'root',
  'ssh-options' => '-p 60022',
  'command-specific' => array (
    'sql-sync' => array (
      'no-cache' => TRUE,
    ),
  ),
  'path-aliases' => array(
    '%dump-dir' => '/tmp',
  ),
);
greg.1.anderson’s picture

Status: Needs review » Postponed (maintainer needs more info)

I still cannot reproduce this. Someone who is having this problem will have to do deeper analysis.

helmo’s picture

Status: Postponed (maintainer needs more info) » Active

The underlying issue is that any commandline option is passed to rsync unless it's specifically handled.

This code from commands/core/rsync.core.inc does this:

    if ((isset($test_option)) && !in_array($test_option, $options_to_exclude) && (isset($value)  && !is_array($value))) {
      if ($value === TRUE) {
        $options .= " --$test_option";
      }
      else {
        $options .= " --$test_option=" . escapeshellarg($value);
      }
    }
  }

Just try this: drush --debug rsync --foo-option @a @b

It might be intended behavior to be able to pass extra options to the real rsync ... but it might be better to define this specifically.
Historically there was a whitelist of rsync options which made sure no other options were passed to the real rsync.

greg.1.anderson’s picture

Regarding #12, please read drush topic docs-strict-options for an explanation of what's going on here. drush --debug --foo-option rsync @a @b will not pass --foo-option on to rsync (but will give also given an error, since --foo-option is not defined).

The reason that --php is different than --include-vcs is that the php option is passed in to drush.php by the drush shell script automatically. The drush script ends as follows:

if [ -z "$php_options" ] ; then
  exec "$php" $php_options "$SCRIPT_PATH" --php="$php" "$@"
else
  exec "$php" $php_options "$SCRIPT_PATH" --php="$php" --php-options="$php_options" "$@"
fi

An earlier version of drush, prior to the implementation of strict option handling, had the --php options at the end of the line, after the "$@". Anyone who is having trouble with --php being passed to rsync should use `which drush` to find out which copy of the drush script is currently being used, and open it up and look at it. If it does not end as shown above, perhaps you are executing an old version of the script copied to another location on your system. That's the only explanation for this problem I can think of.

helmo’s picture

Thanks for the clarification.

I indeed had --foo-option placed after 'rsync'

rteijeiro’s picture

Great!!

I was using the wrong command cause an invalid simbolic link.

Thank you very much and sorry for the inconvenience.

helmo’s picture

Status: Active » Closed (works as designed)

Setting status, feel free to re-open if there is more to do here.

greg.1.anderson’s picture

The solution to the OP's problem is probably in #13, but that has not been confirmed yet. However, I will leave it up to the OP to reopen if #13 is not the answer.

ryddler’s picture

Status: Closed (works as designed) » Active

Sorry for the delay in responding, I've been busy on other projects since this ticket was opened.

#13 could possibly be the answer, because the tail of my drush file looks like so:

# Pass in the path to php so that drush knows which one
# to use if it re-launches itself to run subcommands
exec $php "$SCRIPT_PATH" "$@" --php="$php"

Clearly these are different files, but how can I know which version I have, because there is no version information in the script. Since the file was put in place by drush itself, and should be updated by drush whenever I issue the command to update, I would still consider it a bug.

I would also suggest that the script also have the version added for ease of troubleshooting, and verifying that the latest version is installed.

Now, since drush did not update this file when I updated drush, where can I find the newer version that is referenced above?

greg.1.anderson’s picture

Category: bug » support
Status: Active » Fixed

It looks like you have a corrupted install of Drush with mismatched files. If you have a "drush" script anywhere on your system other than inside the "drush" folder, please remove it. If you need/want the "drush" script somewhere else (e.g. /usr/local/bin), make a symbolic link; do not copy. I tend to prefer to update my $PATH to include the "drush" folder rather than putting drush in a place that is already in the $PATH, myself.

I would recommend removing the "drush" folder and re-installing from scratch, perhaps using PEAR as described on the project page.

The version of Drush is stored in the .info file, not in the drush script or any other code file in the package. Versioning individual files would not be maintainable.

moshe weitzman’s picture

Category: support » bug
Status: Fixed » Closed (works as designed)

drush no longer updates itself. the update process is briefly explained on the drush project page. you can also get the drush version using `drush version` command or even more info with `drush status`