Closed (works as designed)
Project:
Drush
Version:
7.x-5.2
Component:
Core Commands
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
25 Apr 2012 at 17:51 UTC
Updated:
12 Jun 2012 at 18:21 UTC
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
Comment #1
patcon commentedWhoa. 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
Comment #2
patcon commentedYou should be able to reproduce the error with this and drush 5.1 (only work with PHP 5.3.x)
Comment #3
patcon commentedSeems a start:
http://drupalcode.org/project/drush.git?a=search&h=HEAD&st=commit&s=--php
Comment #4
patcon commentedhmmm... maybe an arv conflict in my case... composer uses it
http://drupalcode.org/project/drush.git/commitdiff/a071db30cb4d0c0a8e8f3...
EDIT: nevermind. not composer-related
Comment #5
greg.1.anderson commentedYeah, that sounds wrong all right. --php probably just needs to be declared a global option. Funny this wasn't noticed earlier.
Comment #6
greg.1.anderson commented'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?Comment #7
patcon commentedDefinitely 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
Comment #8
rteijeiro commentedI am getting the same info with the 5.2 version. Here you are my debug output:
Hope it helps.
Comment #9
greg.1.anderson commentedWhat are the contents of your two alias definitions?
Comment #10
rteijeiro commentedHi. This is the content of my two alias definitions (only pasted te code of the site I am rsyncing):
LAMP
VPS
Comment #11
greg.1.anderson commentedI still cannot reproduce this. Someone who is having this problem will have to do deeper analysis.
Comment #12
helmo commentedThe 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:
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.
Comment #13
greg.1.anderson commentedRegarding #12, please read
drush topic docs-strict-optionsfor an explanation of what's going on here.drush --debug --foo-option rsync @a @bwill 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:
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.
Comment #14
helmo commentedThanks for the clarification.
I indeed had --foo-option placed after 'rsync'
Comment #15
rteijeiro commentedGreat!!
I was using the wrong command cause an invalid simbolic link.
Thank you very much and sorry for the inconvenience.
Comment #16
helmo commentedSetting status, feel free to re-open if there is more to do here.
Comment #17
greg.1.anderson commentedThe 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.
Comment #18
ryddler commentedSorry 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:
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?
Comment #19
greg.1.anderson commentedIt 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.
Comment #20
moshe weitzman commenteddrush 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`