terminus
terminus copied to clipboard
Error with Drush
Expected behavior Run Drush commands with Terminus 1.1.1 or 1.1.2-dev
Actual behavior Returns Exit 255 error with any Drush command.
Steps to reproduce the behavior PHP binary C:\Program Files\PHP\v7.0\php.exe PHP version 7.0.9 php.ini used C:\Program Files\PHP\v7.0\php.ini Terminus project config Terminus root dir C:\vendor\pantheon-systems\terminus Terminus version 1.1.2-dev Operating system build 14393 (Windows 10)
Just a bit more info on this one: This is Terminus, installed on Windows 10, in the GitHub Desktop default shell.
Terminus commands are working.
Terminus drush commands fail
for example *terminus drush "cc all" returns
[notice] Command: drupalbase-master.dev -- drush cc all [Exit: 255] [error]
Installing a local version of drush did not help (although attempting to use drush aliases return an EOF error)
In Terminus 1.0 and later, Drush should be called as follows:
$ terminus drush site.env -- cc all
Quoting the Drush command and parameters was how Terminus 0.x did it, but now Terminus is following the standard used in Symfony Console.
Thanks. Yes, I ran the command without the quotes. Terminus itself runs fine. It's only using Drush when the 255 pops up.
I was able to get things running by forgoing the Git shell and using CygWin. What's odd is Terminus 0.9 was running fine on my machine using the Git shell. Only after updating to 1.2 did the errors appear. Even downgrading would not fix the issue. Getting it all running with CygWin was still not without challenges. It was certainly not as simple as getting 0.9 running a few months ago.
If anyone finds this problem, I may have an answer for you. I had the same problem and found the answer.
For some reason, the ssh connection between terminus and the remote drush requires your ssh keys to be named precisely one of the following:
id_rsa
id_dsa
id_ecdsa
id_ed25519
Ensure that your ssh key is named one of the previous if you're having this problem.
I was trying to run SQL commands via Terminus and Drush. I found that removing the semi-colon (;) from the SQL statement fixed it.
In my case, this issue was not due to the syntax or the name of the SSH key as suggested above. Rather, I was able to resolve this by following the workaround in https://github.com/pantheon-systems/documentation/issues/6778