Improve php executable location detection logic

I committed the port fix. As for the drush.php change, I'm not sure. Assigning to adrian.

I just took a look at the "CGI" issue - it's not really anything to do with CGI as such, but that the #!/usr/bin/env php shebang picks up the non-cli version of php, which is compiled to runs in a restricted environment. This is not a super-uncommon configuration, I think (if we include odd cgi/apache php.ini configs not well suited to the command line). This could be fixed on the specific environment by either (a) editing drush.php to start with #!/usr/bin/env php-cli or using some kind of wrapper/alias or (b) by altering the system env config so it finds the cli version from the command line but not from Apache, obviously - which might be a bit tricky where the cgi is running in essentially the same environment.

To fix how drush works is a bit harder. We can't just use #!/usr/bin/env php-cli, because env isn't quite smart enough to use the regular php (which is really the proper command line one on many systems) if php-cli is not found. I couldn't see a way to add logic to the shebang so that it only checks php is php-cli is not found - I am pretty sure it only runs a single binary.

A more flexible solution would be to distribute a simple wrapper script (probably named just "drush") that does a conditional check to figure the best interpreter. There is perhaps a minor performance penalty for doing this, but it should br pretty minimal.

The advantage is that we could tweak this over time perhaps, to add a little logic on common sandbox setups and missetups, (such as MAMP on OS X where drush ends up picking up the crappy half-broken built-in OS X php, rather than the MAMP one) that could make drush easier for folks new to the command line to pick up. Of course, because this is a separate wrapper there is nothing forcing people to use it - they are free to continue running drush.php directly if they prefer (and it works on their system).

Anyway, a "drush" script (rename and chmod as appropriate) that works for me is attached - I have checked that it works on my Ubuntu desktop and on the same fastcgi environment that Bevan mentioned. Timing it, it seems to add about 0.01-0.02 seconds to the executon time, which feels pretty reasonable to me.

I don't have a Mac handy, but if someone feels like adding a check for the main MAMP php cli binary (and if so use that before the env php) that might be worthwhile too.

Works for me. Our other option is probably less tasteful - don't include a shebang and have users put /path/to/php in their alias.

MAMP works for me today as is. I guess I might have customized my $PATH. The usual problem with MAMP is finding mysql socket file, not php (AFAIK). Anyway, php is at /Applications/MAMP/bin/php5/bin/php.

It looks like MAMP is indeed an issue on an out-of-the-box install - see http://raincitystudios.com/blogs-and-pods/steve-krueger/how-use-drush-lo... - so I added a check for that and committed.

I also added an export COLUMNS at the top, which should make this available in most new user setups without them needing to add it to their .profile, or us needing to execute a system() command to figure this out.

Finally, I updated the README file, to direct new users to chmod u+x and use 'drush' (rather than drush.php) by default. I left in a note for advanced users explaining that they can still use a specific php binary to execute drush.php directly.
It might be worth someone having a read through the README and make sure it is grokkable.

Owen,

I spotted a type, possibly resulting from this change. There are two "the" words in "you need to add the line 'export COLUMNS' to the the .profile file in your".

More importantly, the change you committed allows drush to execute, but doesn't pass any parameters. I had to make some changes (in the attached patch) in order to DO anything with drush.

I think the changes in this patch are pretty hacky, and imagine there is a better way to do this that I am unaware of.

I committed a variant of this that uses "$@" (probably the better way you were thinking of!). It also includes a fix so that it leaves you in the right directory, and fixes the typo you mentioned.

This seems to work fine in my both my local mamp desktop sandbox, and the aforementioned fastcgi environments. Thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.