1

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?

  • This is not really Drupal-related: you have a broken PHP install. So you need to fix it. Make sure you can run php -v from shell from any path, and it returns version you expected, and you'll be OK. – Mołot Sep 16 '14 at 21:06
  • Even if your PATH seems okay from your login shell, sometimes redispatches will break as described above if your bash environment (.bashrc contents) are not right. While this may not be "Drupal related", it is sometimes difficult for some folks to get right; Drush therefore checks the DRUSH_PHP environment variable in preference to your other environment settings. DRUSH_PHP is Drush / Drupal related, so I think that makes this question on-topic for Drupal answers. – greg_1_anderson Sep 17 '14 at 0:04
  • Is this related to the fact that I had to 'fix' the PHP-PATH due to my previous issue? See previous recent issue, "Drush on Macbook Pro will not read Drupal correctly"? That is why I wanted to keep this post with the previous question, but the sys-op deleted my question suggesting I make a fresh question so now I have to rebuild the previous circumstance doubling my communication. – ChandraSwami Sep 17 '14 at 0:49
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.)

  • But it seems like Drush DOES KNOW where to find the PHP PATH. I have explicitly created a PATH reference in the .bash_profile. This issue is only with the sh-shell call. Otherwise Drush is able to do all its main commands. I just finished creating an Omega-Subtheme and set it as the default with this very Drush. Tomorrow, when I get some free time, I will post my .bash_profile innards and then I will get feedback if anything is wacky, which might well be the case. I am new at all of this .bash_profile stuff. – ChandraSwami Sep 17 '14 at 1:01
  • To greg_1_anderson. How do you 'initialize' a PATH, in the .bashrc file? I know how to 'export' and how to 'alias' but I am not clear what it means to 'initialize'. Sorry for my ignorance, I checked the web for explanations, but was not able to find anything. Could be using the wrong search words. – ChandraSwami Sep 18 '14 at 19:09
  • I just meant "export". – greg_1_anderson Sep 18 '14 at 20:55
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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