I'm having a problem when executing a drush command on a group of aliases that are all remote.

When I do this:

drush -y @group.host1 status -v

all works fine.

When I do that:

drush -y @group status -v

it fails with the following message for each host in that group:

ssh -o PasswordAuthentication=no host1 'DRUSH_PHP=/usr/bin/php drush  --backend=2 --verbose --yes --uri=www.example.com --root=/var/www --reserve-margin=28  status 2>&1' 2>&1
fish: Unknown command 'DRUSH_PHP=/usr/bin/php'. Did you mean to ru
n drush with a modified environment? Tr
y 'env DRUSH_PHP=/usr/bin/php drush…'. See the help section on the set command by typing 'help set'.
Standard input: DRUSH_PHP=/usr/bin/php drush  --backend=2 --verbose --yes --uri=www.example.com --root=/var/www --reserve-margin=28  status 2>&1

So, how I read the error it looks like fish (which is the shell used instead of bash) is having an issue with the command

ssh -o PasswordAuthentication=no host1 'DRUSH_PHP=/usr/bin/php drush  --backend=2 --verbose --yes --uri=www.example.com --root=/var/www --reserve-margin=28  status 2>&1' 2>&1

Now what's the difference when I call the same thing for @group.host1 instead of @group? Then the command looks like this:

ssh -o PasswordAuthentication=no host1 'drush  --backend=2 --verbose --yes --uri=www.example.com --root=/var/www --reserve-margin=28  status 2>&1' 2>&1

The difference is that the leading "DRUSH_PHP=/usr/bin/php" is missing and then it works fine.

I have played around with /usr/bin/drush and removed the option --php="$php" from the last line in that file, and then everything works fine again too.

Important: This only happens since I've upgraded to Drush version 6.2 - before I had 6.0 on my local laptop and 5.9 on the host1.

1 Answer 1


Drush was designed for use with bash, not fish. Would it be an option to make your login shell bash for your remote Drush user?

Your other option would be to submit a patch to Drush to fix this problem. There are two possibilities:

  1. Modify Drush to use env DRUSH_PHP=... in backend invoke.

  2. Modify Drush to not pass --php when --remote-host is set.

Option (1) may be harmful to remote sites where env is not in the PATH, so it may be a dubious proposition. It might be okay, though; env is probably in the PATH on most systems.

Option (2) seems better. There is little reason to think that the path to php will be the same on a remote system as it is on the local system, so Drush probably shouldn't be assuming that the php option is relevant for remote aliases, unless it was set in the alias' %path section.

Either of these actions would require a discussion in the Drush issue queue.

  • Thanks Greg, that's what I thought too and I'm in favour of option 2 as well. I'll move this over to the issue queue but there is one more question in the context here: why does Drush behave differently for individual aliases compared to a groupd of aliases then?
    – jurgenhaas
    Commented Dec 13, 2013 at 7:04
  • Thinking about it I cam across a third option: 3. Force the remote host to use bash by start the command with /bin/bash -c "...." where .... gets replaced with what ever Drush wanted to execute already. That way it will still work even if other stuuf makes its way into the command line which might be incompatible with alternative shells.
    – jurgenhaas
    Commented Dec 13, 2013 at 12:17
  • 1
    Looks like drush is already aiming for approach 2 above and it "fails" for groups. I have analyzed the code and filed an issue over at github, see [github.com/drush-ops/drush/issues/324]
    – jurgenhaas
    Commented Dec 13, 2013 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.