Drush assumes php 5.3 on MAMP when it shouldn't

Seems reasonable to me to adjust the order to check for 5.3 before 5.2 as you have done in your patch, but just to make sure that I'm not missing something, when you said "I have set it to run php 5.2", what did you mean?

php 5.2 comes pre-installed in a lot of recent Linux distributions, so perhaps 5.2 was listed first because it was considered better-tested. php 5.3 is pre-installed in Ubuntu 10.10, though, so I imagine that it will be considered more standard than 5.2 soon (now?).

Getting back to my question, I am unfamiliar with MAMP, so I don't know what you mean when you say "I have the option to choose what it runs, 5.3 or 5.2". What is the effect of changing one vs. the other? Does it adjust your $PATH? The issue you were originally having is that drush was not, by default, selecting the same php that you selected howevertheheckyoudothat as described in #3.

The issue is clearly the code that you patched, but the purpose of that code is to select the "right" php when *AMP installers are in place. Your patch makes the default right for you, but might break other people who are using *AMP with 5.2. The big question is, is there a way that the drush script could use to tell the `which php` is returning the 'right' php per the user's selection, so that the icky *AMP special-checking could just be skipped? That would be better.

Okay, I was confused by #3 slightly. You have selected php 5.2. Drush was instead selecting php 5.3. Your patch makes drush select php 5.2, because the loop in the drush script is last-found-wins.

I am reluctant to accept this patch, because in the absence of any information on which php the user has selected, it makes the most sense to pick the newest version of php that is installed.

If you do not want to use php 5.3, then uninstall it, or just rm the file that drush is looking for in the *AMP special-case code.

Part of the problem with MAMP is that it
$ which php-cli
doesn't return anything.
$which php
does return the path to the binary

I don't think it's fair to ask MAMP users to move or rename the /Applications/MAMP/bin/php5.3/bin/php executable just for drush.
In the case of MAMP, we should ideally line up with what version of php-cli is running. We could check that, and then set the corresponding path to the binary. I'm not sure how to accomplish this in code.

Alternatively, how about providing a function in drushrc.php to manually override $drush_php_ini?
Both MAMP paths could be commented out as options to the user.
Otherwise, a more global $php_version variable could be set to 5.2 or 5.3, and that could be used to build the specific path to binary.

In the meanwhile, here is my hacky solution attached. Building on the last-found-wins approach, I've simply added an additional path option at /usr/local/bin/php, so the user can manually override.

btw - I tried symlinking my MAMP 5.2 php.ini, but it didn't work so well:

Warning: PHP Startup: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in Unknown on line 0

Warning: PHP Startup: pdo_mysql: Unable to initialize module
Module compiled with module API=20060613
PHP    compiled with module API=20090626
These options need to match
 in Unknown on line 0

*AMP is out of my area of experience. I guess I am okay with the proposed patch. I'd like to say that we should just kill the drush *AMP code and always go with what the user has set up, but the issue with *AMP is that often users expect to use a different PHP with their cli than with Drupal, drush needs to be in alignment with what Drupal is using, and setting this up correctly was deemed to be difficult for some users.

drushrc.php is too late to fix up your php.ini or php choices, as you have already selected your php executable and loaded your php.ini before you parseyour drushrc.php file (which is in php, of course).

Frankly this whole code needs to die. Setting the correct PHP executable is as easy as setting the PATH correctly, and should be part of the installation process. If you environment is broken (like OS X and MAMP both shipping with conflicting versions of PHP), you should fix it, not ask the whole world (here: Drush) to work around it.

I do agree that it would be better if drush picked up the path to the executable instead of hardcoding it. As it currently stands, drush ignores what you've set in your PATH if you happen to have one of the listed *AMPs installed.

I'm with Damien on this one. I hate having MAMP/XAMP specific code here; The logic is always so fragile.

I'm for stripping all the MAMP stuff from Drush and just having a couple commented out examples in drushrc to whichever php binary you're using.

Hmm. Moshe reminded me that the binary is already chosen by the time we get to drushrc. Not sure what the best option is in that case.

How about if we remove the *AMP stuff from the drush script, and commit a drush-AMP script? Then folks who a) use *AMP and b) don't want to set their PATH correctly can just make a symlink from /usr/local/bin/drush (or wherever) to drush-AMP. Is that easy enough?

Sounds complicated.
How about we just cut out the *AMP section and amend the read me file to make more clear the instructions on setting $drush_php in the user's .profile, i.e.
export DRUSH_PHP='/Applications/MAMP/bin/php5.2/bin/php'
in case the user wants to use a different php-cli for drush than their system?
This would be the same place they'd set the PATH to the *AMP php-cli.
This way all the cli configuration is in the same place for the user, rather than hopping around creating symlinks?

We can list the common paths for the *AMP distributions in the README.txt
I am happy to rewrite this if it is the will of the people.

#15 gets my vote.

I'm in favor of this as well, but I'd like to hear from Moshe on this since the original intent behind this was to reduce support requests.

Sounds sensible to me too. Thanks for volunteering to improve the README. Feel free to be verbose for the newbs.

Even though drush is pretty broken on Windows, we need to keep things from deteriorating. What do we do about drush.bat? I imagine Windows folks like using that.

Let's cover Windows under a separate issue. Kulov and I will be submitting some issues to the queue on this subject in 3~6 weeks or so.

Sounds good to skip Windows here. Awaiting bash script and README patch ..

I will get to these soon. Happy to help.

So… I started editing the README file and it has turned out to be a much more comprehensive rewrite than I intended. I've been doing incremental commits to my local git branch. A bit more left, still. I hope this will work out.

README.txt is almost completely new with this patch. I tracked multiple commits with git in my local branch, but I can't quite figure out how to commit those back so the changes can be reviewed incrementally. I'm new to git so a bit lost with when to merge or rebase. My attempts to commit say "nothing to commit (working directory clean)".

I felt that the README file has been patched together for a long time and lacked consistent formatting and tone. Mainly, though, most of the concepts in the file were impenetrable to newbs.

Maybe I got carried away with the editing? I dunno… I feel justified.

Overall, this is a really big improvement to README.txt. Thank you.

Regarding the specific advice given to *AMP users, in the past, some users have complained that it is not reasonable to expect their $PATH to be set correctly for their *AMP components, because their system might use one version of Mysql for their desktop applications, and a different version for their Drupal / drush installation. In this case, the Mysql in the $PATH must point to the version needed by the desktop applications. (I don't use this configuration, I am just reporting what I have heard -- feel free to post a rebuttal if you have another idea about how this should be set up.)

Anyway, if the above is true, then one workaround would be to advise *AMP user to always run drush in core-cli mode. If you do this, then drush will load the .bashrc file from your $HOME/.drush or /etc/drush folder; you can then adjust your $PATH so that the *AMP components come first. e.g.:

In $HOME/.drush/drushrc.php

PATH=/path/to/AMP/mysql:$PATH

It is a little lame that the drush sql commands won't work unless you go into core-cli mode first. Perhaps we could add a feature in the drush script to adjust the path. e.g.:

In drush:

if [ ! -z $DRUSH_PATH ] ; then
  PATH=$DRUSH_PATH:$PATH
fi

Untested, but that's the general idea. Then we could advise *AMP users to set DRUSH_PATH to contain those *AMP paths that should override their usual PATH list.

How does that idea sound?

Users wanting to use a different MySQL for Drush than the one that is found in their $PATH sounds link an extreme edge case to me.
Wouldn't Drupal constitute one of these "desktop" applications? Are these users setting specific connection strings in their settings.php then?
Most AMP users I know of want to override their system configurations.

It would help to better understand what the circumstances we are trying to address are. Is there an issue you can refer me to?

If we want to point Drush a different binary for MySQL, from a configuration standpoint it would make sense to address this in the same way that we do for PHP, with and environment variable in the standard ~/.profile, like so:

export DRUSH_PHP='/path/to/php'
export DRUSH_SQL='/path/to/mysql'

Now, I don't know what would be involved in refactoring the code to handle this, but the logic seems sensible, no?

I could not find the issue that discussed why just setting the PATH correctly was not an option for some *AMP users. @moshe, do you remember? If no one does, then perhaps we should implement per #23, and let the affected individuals come back to the queue and tell us why it was a bad idea. :p

At one point there may have been a certain elegance to drush working out of the box with MAMP, but now that they have the option to switch between php 5.2 and php 5.3, with no way to export that setting to an environment variable anyway, it makes a lot less sense for drush to try to figure out which version you're currently using.

I have my PATH set correctly, am using MAMP PRO, and installed drush 4.4 via homebrew, and I also (at this point) don't see the need for the extra *AMP logic. I believe that it would be far easier to simply explain how to setup your .bashrc correctly (see my setup below), and use the php that coincides with a correctly configured command line environment, than anything else.

When I need to switch MAMP PRO from php5.3 to php.5.2, I must:

1) change the php version in the MAMP PRO Administrative GUI and reload MAMP.
2) add the path/to/correct/php/bin the PATH environment variable. (since MAMP doesn't do this for me)
3) Either:
3.a) ensure the custom *AMP code is commented in the drush bash script or
3.b) add a DRUSH_PHP line to my path, that uses the correct MAMP php version.

I currently use 3b, but if we got rid of the special case *AMP code in the drush bash script, I wouldn't even need the additional export DRUSH_PHP in my bashrc!

excerpt from .bashrc

export PHP_VERSION='5.2'
export PHP_HOME='/Applications/MAMP/bin/php$PHP_VERSION'
export PATH='$PHP_HOME/bin:$PATH'
export DRUSH_PHP='$PHP_HOME/bin/php'

It boils down to determining whether or not we can safely assume that if you're venturing in to using drush, you've signed yourself up to learn how to edit your environment variables. Is there any case when someone using an *AMP cannot customize their environment variables?

I vote less config & less special cases:

a) default to use the php from $PATH,
b) if you want something else, force it with the custom DRUSH_PHP environment variable,
c) or as a last and final resort, specify the absolute path to php and call drush.php verbosely which is often necessary if you're running drush as a cron job.

Ok, lets proceed with #23. I'll let Greg do the commit as he has reviewed it.

I can agree with #27. Perhaps my concern from #24 is about an issue that is now obsolete.

Did not mean to change the assignments -- simultaneous save issue again. I'll do as moshe says in a bit.

I'd point out that it's necessary to edit the $PATH to ensure that MAMP's mysql binary is included in order to use the `drush sql-` commands with MAMP anyway, so there's no reason why not to also require the right PHP binary on the $PATH as well.

A complete working MAMP .bashrc setup, including Developer tools dependencies:

export PHP_VERSION="5.2"

# HOME folders
export DEVEL_HOME="/Developer"
export MAMP_HOME="/Applications/MAMP"
export PHP_HOME="$MAMP_HOME/bin/php$PHP_VERSION"

# DRUSH
export DRUSH_PHP="$PHP_HOME/bin/php"

# PATH
export PATH="$DEVEL_HOME/Tools:$PATH"
export PATH="$MAMP_HOME/bin:$PATH"
export PATH="$MAMP_HOME/Library/bin:$PATH"
export PATH="$PHP_HOME/bin:$PATH"

#MANPATH
export MANPATH="$MANPATH:$MAMP_HOME/Library/share/man"
export MANPATH="$MANPATH:$DEVEL_HOME/share/man"

oops, was editing while you were changing status. my bad. unfortunately i cant assign it back to you :/

No problem. Is there any point in including #31 in drush's README.txt? That is, doesn't this info appear in the MAMP documentation? If so, seems it would be sufficient to document just DRUSH_PHP, and also reference that your *AMP 'bin' dir should also be in your $PATH.

#31 is a verbose way of setting the path to MAMP's php mysql in your $PATH.
All these options are covered in a more catch-all way in the README.txt, with the exception of the lines about Developer tools.

Okay, I'll stick with #24 w/ minor edits.

#24 does not apply to master. I'm not sure why; looks like it should.

I was working off 4.x-dev

Could you re-diff against 5.x-dev head? There are some changes in the README in master.

Nevermind, the changes in 5.x-dev were not significant. I've got a reconciled README.txt; I'm going to edit and commit it.

Committed. The one functional change I made was:

To see which php.ini file the webserver is using, use the phpinfo() function
in a .php web page.  See http://drupal.org/node/207036.

The advice previously given returned the php.ini used by php-cli instead of the webserver php on my system.

My previous and shorter version of #31 configuration was:

$ cat ~/.profile 
PATH="/Applications/MAMP/Library/bin:/Applications/MAMP/bin/php5.2/bin:/Applications/MAMP/bin/php5.3/bin:$PATH"

BTW.
If .bashrc is not parsed by Terminal, add following code into your .bash_profile

if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

source ~/.bashrc

Here is my path @kenorb:

export PATH="$PATH:/Applications/MAMP/Library/bin:/Applications/MAMP/bin/php5.2/bin:/sw/bin:/usr/local/bin:/usr/bin:."
No need to have both the paths to php5.2 and php5.3 in there at the same time.

Personally, I'm happy with keeping everything in .bash_profile
Mac OS X's Terminal runs a login shell by default for each new terminal window, calling .bash_profile instead of .bashrc, so it's more straightforward that way.

There is a fair bit of variance from platform to platform on exactly which of .bash_profile, .bashrc, .bash_aliases, .bash_customizations & c. are called, so I would not want to be too specific about the advice we give about this in the README.txt. #41 would cause .bashrc to be loaded twice on some systems.

I'm still open to improving this info if anyone has any suggestions on how to enhance the directions in a general way.

I'd also vote for the cleaner, shorter way of doing things in the README, and it's probably better that the instructions use .bash_profile instead of .bashrc... I, myself, put all of the environment variables in .bash_environment, but didn't mention that above in an attempt to avoid further confusion, but i guess that even had its technicalities as per #41, sorry :-|

If someone really cared about having the "complete MAMP setup" like mine, they can always refer to comment #31, which brings up a good point... Would linking to this issue be a good thing to include in the documentation, so people come here first before opening up new issues concerning MAMP configuration?

I'd suggest sticking with the basic bash example, since its probably the most common default shell on many platforms.

Could we then offer instructions to search google for how to set environment variables for their specific operating system and shell variant?

re patch in #23: (sorry for extremely late review)

+* Drush is designed a Unix-like OS (Linux, OS X)

Is that supposed to read as "Drush is designed for a Unix-like OS"?

#46 is correct.

re #45: the new readme in 3.b lists various configuration files but does not make an assumption moving forward which config file the user is using. The beginning of the file tells people to read up on bash if they're unfamiliar. The example configuration files are listed as a shortcut for newer users. Most likely, whichever of those already exists in their home folder will work for them.

re #44: I don't think issue queues are the place for instructions. I would suggest a child page here instead:
http://drupal.org/node/66187
The path issue is rather specific, and there will be lots of comments on this point that will detract from the basic MAMP setup parent page.

Please be verbose with the MAMP folks in the README. If we don't spell out exactly which file to edit, and how, they will just use the issue queue for support. Or they blog and twitter about how drush is "hard for normal folks".

A little more verbosity for *AMP users; please review.

The configurations carried over from #31 are confusing to an entry-level audience due to the circularity of many of the variables.
It is a creative configuration, but I think we need something more straight-forward.

In order to provide clear instructions to MAMP users, as requested by @moshe, I have rewritten this section, also with a view to provide something that can be approached with a cut-and-paste methodology.

Please see the attached patch (this time applying to HEAD).

I still agree with Andrew. I don't like the idea of sticking my verbose and creative bash example in drush's readme (a la #49), but can definitely sympathize with Moshe's desire to get more verbose.

Review of #50:

+To use php 5.2.x, add this line to .bash_profile:
+
+  export PATH="$PATH:/Applications/MAMP/Library/bin:/Applications/MAMP/bin/php5.2/bin"
+
+If you want to use php 5.3.x, add this line instead
+
+  export PATH="$PATH:/Applications/MAMP/Library/bin:/Applications/MAMP/bin/php5.3/bin"
+
+If you have MAMP v.1.84 or lower, this configuration will work for both version of php:
+  
+  export PATH="$PATH:/Applications/MAMP/Library/bin:/Applications/MAMP/bin/php5/bin"

Have you actually tested that any of these work? I would think that you'd need to put the MAMP bins /before/ the preexisting $PATH, so that Mac os X's default php is not used.

Otherwise, good changes.

will rtbc if you can confirm my doubts in #51.

Not to derail this issue again, but I wanted to throw this idea out and see if anyone else liked it.

What if we just wrote out a ~/.drushrc file, that'd contain something like this:

#export DRUSHPATH=/Applications/MAMP/bin/php5/bin # MAMP (<=v.1.84)
#export DRUSHPATH=/Applications/MAMP/bin/php5.2/bin #  MAMP (>v.1.9+)
#export DRUSHPATH=/Applications/MAMP/bin/php5.3/bin # MAMP (>v.1.9+)
#export DRUSHPATH=/Applications/acquia-drupal/php/bin   # Acquia Dev Desktop (Mac)
#export DRUSHPATH=/Applications/xampp/xamppfiles/bin #XAMP (Mac)

if [[ -n "$DRUSHPATH" ]]
then
  export PATH=$PATH:$DRUSHPATH
fi

Then we could either source that when we try to find the php binary or do something like echo "source ~/.drushrc" >> ~/.profile.

This way, all the *AMP user would have to do is uncomment the one line they need.

@ jrguitar21 thanks for catching that.
$PATH has been adjusted in this new patch

I definitely like the cleanliness and the intentions of the idea proposed in #53, but it will also mean that people will have to then make changes in two places [.bash_profile and .drushrc] to get drush to work with MAMP which is maybe not so good for Noobs (?). #31 mention's that you need to add MAMP's mysql to $PATH, which should be done in .bash_profile. Currently, the changes in #54 kill all the birds with one stone.

Line up the ending comments, and put them on the path first (as per #51) were we to go with this option:

#export DRUSHPATH=/Applications/MAMP/bin/php5/bin:/Applications/MAMP/Library/bin     # MAMP (<=v.1.84)
#export DRUSHPATH=/Applications/MAMP/bin/php5.2/bin:/Applications/MAMP/Library/bin   # MAMP (>=v.1.9+)
#export DRUSHPATH=/Applications/MAMP/bin/php5.3/bin:/Applications/MAMP/Library/bin   # MAMP (>=v.1.9+)
#export DRUSHPATH=/Applications/acquia-drupal/php/bin # Acquia Dev Desktop (Mac)
#export DRUSHPATH=/Applications/xampp/xamppfiles/bin  # XAMP (Mac)

if [[ -n "$DRUSHPATH" ]]
then
  export PATH=$DRUSHPATH:$PATH
fi

UPDATE: doh, theres no reason why we couldnt put the /path/to/mamp/library/bin for the mysql binary here!

UPDATE 2: updated the code with mamp library bin. Notsure about acquia-drupal mysql bin, or xampp.

Does .drushrc modify the path for the entire bash session, or just the duration of the drush command?

Reason I ask is that, if not, then 'mysql' won't be available for bash to execute some nice trickery like this:

`drush sql-connect` < ../assets/database.sql

Well, I'm operating at a bit of a disadvantage here, as I don't have a MAMP install to test on; however, I think that #55 is not correct. If we did in fact set the PATH in the drush script (e.g. by source'ing an external file per #53), then that would be sufficient to make everything work for drush.

core-cli already sources $HOME/.drush/.bashrc if it exists, and we already have an example.bashrc file that we could enhance for this purpose rather than make a new filename. If we made the drush script source this file, then perhaps we wouldn't want to also source it in core-cli.

In any event, I think it would be a good idea if someone with an *AMP installation could try this technique out and see if it worked out okay.

well… I wasn't using a ~/.drush/.bashrc file in my MAMP set up.
Drush refused to load the configuration file until I explicitly pointed to it in .bash_profile:

if [ -f ~/drush/.bashrc ]; then
. ~/drush/.bashrc
fi
source ~/drush/.bashrc

OS X is funny this way…

tried both ~/.drushrc and ~/.drush/.drushrc and neither command successfully modified the PATH during the execution of the drush bash script (which is when its necessary to have php set so the drush.php can be called correctly).

Would require some additional code in the drush bash script to look for ~/.drushrc or ~/.drush/.drushrc, and source it if its there. Or have instructions to add lines to .bash_profile (like the previous comment) in drush README, but this seems like even more misdirection, smoke and mirrors, to confound noobs.

I'm not familiar enough with core-cli to know if it would be more useful to have the $PATH modifiers in a .drushrc.example or left as is in README to be added by the end user in .bash_profile.

Regardless of whether the path can be exported, I'm starting to thing that instructions to modify the $PATH in .bash_profile is clearer than instructions on copying an example bash config file and modifying it.

To get the path set right:

exec /usr/bin/env PATH=$DRUSH_PATH $php "$SCRIPT_PATH" "$@" --php="$php"

But again, I no longer think we should do that.

I think we should go with #54.

+1 for commit

I'm with you greg. go for it.

+1 (obviously)

Any desire to also comment out the AMP logic for version 7.x-4.5?
The current solution, otherwise, is to instruct users to override Drush's forceable use of MAMP's php 5.3 by setting an environment variable in .bash_profile, like so:
export DRUSH_PHP='/Applications/MAMP/bin/php5.2/bin/php'
Personally, I have found MAMP's php 5.3 and Drush to not work well together. I imagine others may have had or are currently experiencing similar funk.

We won't backport this to 4.x; our policy is to not backport changes that alter current behavior. We backport new features until 4.x is in debian, then it will be critical bugfixes only.

Patch does not apply anymore AFAICT.

It seems like the patch was committed on Mar 22 2011
(SHA: 477f21c0cb9677e695abdf38d055bab6500fc896)

Let me know if I should do anything else.

#54 was an adjustment to the 22 Mar commit that I have not processed yet.

Subscribe. It seems, after reading through this issue and the Gist that was linked above, one can at least get Drush working locally on a Mac using MAMP by entering the following the command line (to explicitly define the 5.2 PHP version supplied by MAMP:

export DRUSH_PHP='/Applications/MAMP/bin/php5.2/bin/php'

Finally committed #54.

http://drupalcode.org/project/drush.git/commit/fcd74f1