Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I've got drush 6.0-rc4 installed locally and on the server.
If I do "drush @example.prod -v custom-command 1375148040" where the 1375148040 is an argument to a command, then the job fails:
The drush command '1375148040' could not be found. Run `drush [error]
cache-clear drush` to clear the commandfile cache if you have
installed new extensions.
But I tried doing a "drush @example.prod -v cc drush" and that didn't help. And I tried sshing to the production webserver and from there when I do "drush @example.prod -v cc drush" or even the full "drush @example.prod -v custom-command 1375148040" - both of those work fine from the webserver.
Any ideas why this would fail after the upgrade from 5.4 to 6.0.0rc3 or 6.0.0rc4?
Comments
Comment #1
greg.1.anderson CreditAttribution: greg.1.anderson commentedRun with --debug, and report the results. Seems that maybe the remote end is confused, thinks this is a drush shell script, and is popping off too many arguments. But that's just a guess; running with --debug will show if the remote end is involved or not.
Symptoms are different for me.
Comment #2
gregglesMoshe figured out a key piece - the remote command must exist in the remote alias and not locally. He had me test a patch that fixed it. I'll leave it to him to post the patch.
Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedFixed in 8de2b07. The issue is that $command was sometimes FALSE and unfortunately isset(FALSE) evaluates to TRUE so we were recognizing FALSE as a command name which is no good.