Drush commands error with "env: drush9: No such file or directory"

[geerlingguy]

My system information:

• Operating system type: macOS
• Operating system version: 10.12.2
• BLT version: 8.6.5

When I run this command:

$ drush @projectname.test status -v

I get the following output:

Include /Users/jeff.geerling/Sites/acquia/projectname/drush                                                            [notice]
Loaded alias @projectname.test from file                                                                               [notice]
/Users/jeff.geerling/Sites/acquia/projectname/drush/site-aliases/aliases.drushrc.php
Begin redispatch via drush_invoke_process().                                                                    [notice]
Calling proc_open(ssh -o PasswordAuthentication=no [email protected] 'env COLUMNS=120 drush9  --config=/Users/jeff.geerling/Sites/acquia/projectname/drush/drushrc.php --alias-path=/Users/jeff.geerling/Sites/acquia/projectname/drush/site-aliases --verbose --root=/var/www/html/projectname.test/docroot --uri=stage.ecommunity.com  core-status 2>&1' 2>&1);
env: drush9: No such file or directory
End redispatch via drush_invoke_process().                                                                      [notice]

And I expected this to happen:

• The drush command should work.

I found this issue when trying to run blt local:refresh after upgrading a really old BLT-powered site from BLT like 8.1.0 to 8.6.5... and it looks like the issue is the policy_drush_sitealias_alter() in

blt/template/drush/policy.drush.inc

Line 10 in 138fc0c

&& strstr($alias_record['uri'], 'acquia') !== FALSE

looks for the string acquia in the alias' uri to detect when to alter the drush9 to drush8 call...

We are using a custom aliases.drushrc.php file in our project, and define the alias using the live domain of the site for the uri (instead of the Acquia one).

[geerlingguy]

I had the alias set up like this:

$aliases['projectname.test'] = array(
  'root' => '/var/www/html/projectname.test/docroot',
  'ac-site' => 'projectname',
  'ac-env' => 'test',
  'ac-realm' => 'prod',
  'uri' => 'stage.projectname.com',
  'remote-host' => 'staging-123.prod.hosting.acquia.com',
  'remote-user' => 'projectname.test',
  'path-aliases' => array(
    '%drush-script' => 'drush' . $drush_major_version,
  )
);

I had to change the URI to:

  'uri' => 'projectnamestg.prod.acquia-sites.com',

and now it looks like things are working correctly.

But is there a way we can support the 'real' URIs in drush aliases? Sometimes things like migrations, search indexing commands, etc. need the real URI otherwise some things in the database/Solr will end up with the wrong domain.

[grasmash]

@geerlingguy This stems from the fact that we use drush 9 for BLT, but Acquia Cloud does not support drush 9. We get around this by using hook_drush_sitealias_alter() in policy.drush.inc to specifically use drush8 rather than drush9 for any drush alias that contains the string "acquia".

[geerlingguy]

Thanks for the fix! Basically, the commit above switches from using uri to using remote-host, which should more often be the acquia hostname.