Drush returns "sh: php: command not found, code: 127"

Question

Drush returns "sh: php: command not found, code: 127"

I just managed to get Drush working finally on my MacBook-Pro (2008). For the longest time Drush would not interact with the Drupal installation. Turns out the reason for this was the fact that Drush expects to use the default MacBook-PHP which is different from the MAMP-Stack-PHP which is what Drupal will be using.

This was sorted out and now appears to mostly work. My environment is MacBook-Pro with Drupal-7.31 and Drush-5.9. I am using the MAMP-PHP-5.5.14.

The conflicting PHP issue was resolved by renaming the MacBook-Default PHP file by adding an extension to its name. Then the .bash_profile file was modified to add a PATH to the MAMP-PHP and an alias was added for file-name of the PHP that Drush usually expects to substitute the newer MAMA-PHP. If you need the details, those are explained in my other recent question: "Drush on Macbook Pro cannot read Drupal Correctly".

Now there is another issue coming up. When I run a "drush upc" or a "drush owiz" command, I get an error: "sh: php: command not found, code: 127". This seems to be telling me that Drush runs an sh-shell command which cannot locate my new MAMP-PHP file.

Any guidelines in fixing this, if this is in fact what this error means?

Answer 1

Exit code 127 means "command not found", just as the error message says. https://www.gnu.org/software/bash/manual/html_node/Exit-Status.html

If php is in your PATH, then this should not happen. If you want to explicitly tell Drush which php to run, then set the DRUSH_PHP environment variable as explained in the Drush README. This should help out in the case of Drush commands such as the ones you mention before, that run a Drush subcommand in a new process.

Update:

To make things work correctly, you need to understand how bash initializes itself. For example, did you know that .bash_profile is sourced if you run ssh user@host, but it is not sourced if you run ssh user@host pwd? Drush uses the later form to re-launch Drush subprocesses, so if you initialize your PATH in .bash_profile, then it will be fine when you test it in the shell, but it will be broken for Drush subprocesses.

To get around this problem, you should also export your PATH in your .bashrc file, as bash will source this file for non-login shells. Be sure to set up your PATH at the TOP of the file, as there is a line near the top that reads: [ -z "$PS1" ] && return. This causes the script to exit if ssh did not create a tty (run ssh -t to create a tty; Drush adds this flag for interactive commands only.)

Answer 2

RESOLVED. 9/22/2014

I began to discover that the previous method of attempting to change the 'alias' or otherwise redirecting Drush to use MAMP's PHP was the wrong way to go. Especially 'name-distorting' the original MacBook-OS-PHP so that Drush would opt for the MAMP-PHP was causing all kinds of problems with other software, as might be expected. I don't know how this method came to be recommended, but it appears that it is actually a pit-fall.

The way better approach (watch me eat my words in a few weeks), is to rather just upgrade the MacBook-OS-PHP to the same or nearly same version as the MAMP-PHP. Then it does not matter which version of PHP Drush or anything else uses because they are both the same. This overcomes all the issues and is not that difficult to accomplish. At least on my platform which is a MacBook-Pro (2008-Mavericks).

The way that I upgraded my MacBook-OS-PHP was by the CLI-command "curl -s http://php-osx.liip.ch/install.sh | bash -s 5.5".

This is a download from a group of developers in Germany which upgrades your PHP. Check out "http://php-osx.liip.ch/".

Once my System-PHP and MAMP-PHP were almost the same, all my issues with Drush went away. I undid all my 'aliases', 'redirects' and 'name-distortions'. So far all is working well.

Note that on my machine MAMP is using PHP-5.5.14 and my CLI reports with a "php -v" command that MacBook-OS is using PHP-5.4.30 though I am not sure that the version is accurate. In the write up on the PHP-Upgrade it mentions that the version might not be accurate.

By the way this does not OVERWRITE your previous PHP installation but rather just adds a newer installation and directs your system to use it.

I will update if there later prove to be drawbacks in this approach.