> drush php-eval "var_dump(drush_shell_exec('curl --version'))";
  curl 7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
  Protocols: tftp ftp telnet dict ldap http file https ftps
  Features: GSS-Negotiate IPv6 Largefile NTLM SSL libz
bool(false)

Adding a debug statement, the return status of the exac is 2 in this case, even though it returns correct output.

(Seems like a bug in curl, but seems like a bug that people are likely to get so using Bug report, but wouldn't be surprised if it gets set to support request).

CommentFileSizeAuthor
#2 1002934_drush_curl.patch537 byteshefox

Comments

greg.1.anderson’s picture

We could test for curl via 'which curl' to work around this, I suppose.

hefox’s picture

Status: Active » Needs review
StatusFileSize
new537 bytes

Patch attached, seems to work

> drush php-eval "var_dump(drush_shell_exec('which curl'))"
bool(true)
jonhattan’s picture

Status: Needs review » Needs work

`which` is not available on windows, this is why this code test for command availability with curl --version

This is the output in debian stable and testing:

$ drush php-eval "var_dump(drush_shell_exec('curl --version'))";
bool(true)

versions 7.18.2 and 7.21

it seems you're using an old version of curl. From the changelog:

Marty Kuhrt (1 Jun 2008)
- Updated main.c to return CURLE_OK if PARAM_HELP_REQUESTED was returned
  from getparameter instead of CURLE_FAILED_INIT.  No point in returning
  an error if --help or --version were requested.

I don't know how old is darwin9.0 but breaking on windows to support an old version of curl doesn't seem the best option. Perhaps curl --otherthing is possible. Otherwise you just can install wget.

needs work or works as designed. whatever you prefer.

jonhattan’s picture

Status: Needs work » Fixed

so I decided to add `which curl` as a 3rd test if curl --version failed. I'll not make much friends if I ask people to buy a new licence :p

http://drupalcode.org/viewvc/drupal/contributions/modules/drush/commands...

techninja’s picture

Status: Fixed » Needs work

Typo alert!
You probably already caught this, but you put in "drus_shell_exec" instead of "drush_shell_exec" in that last commit

http://drupalcode.org/viewvc/drupal/contributions/modules/drush/commands...

Would have been a nasty surprise for the OSX folks!

jonhattan’s picture

Status: Needs work » Fixed

panic! I need going bargain hunting for a darwin after christmas.

Status: Fixed » Closed (fixed)

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

scott.whittaker’s picture

I'm getting this error message attempting to do a "drush pm-update" using crush 4.5 on Ubuntu 10. Both wget and curl are available and work from the command line to the same user I'm running drush as. In fact I just used wget to download and install Console_Table for drush 4.5 after a "drush selfupdate"

xaqrox’s picture

Title: "wget nor curl executables found." despite working curl » "wget nor curl executables found." in drupal install directory only?
Version: All-versions-4.0-rc3 »
Category: bug » support
Status: Closed (fixed) » Active

Demonstration of this odd behavior:

root@domU-12-31-39-09-F2-38:/var/www# drush dl features
exec(): Unable to fork [wget --version 2>&1] exec.inc:125                                                                 [warning]
exec(): Unable to fork [curl --version 2>&1] exec.inc:125                                                                 [warning]
exec(): Unable to fork [which curl 2>&1] exec.inc:125                                                                     [warning]
wget nor curl executables found.                                                                                          [error]
root@domU-12-31-39-09-F2-38:/var/www# curl --version
curl 7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp smtp smtps telnet tftp 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP 
root@domU-12-31-39-09-F2-38:/var/www# cd ..
root@domU-12-31-39-09-F2-38:/var# drush dl features
Project features (7.x-1.0-rc3) downloaded to /var/features.                                                               [success]

I don't know if this is a bug in Drush or something wrong with my environment, but it sure is weird!

cdmo’s picture

I had a similar error message and resolved it by using ~/.drush/php.ini. See example.php.ini in the drush install package and details in the readme.

dotsam’s picture

Thanks cdmo, that worked for me. I just copied the example form here http://drush.ws/examples/example.drush.ini

dotsam’s picture

Using drush 5.1

greg.1.anderson’s picture

Status: Active » Fixed

Seems this is caused by mis-configured php.ini. Thanks, @cdmo.

Status: Fixed » Closed (fixed)

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

the_g_bomb’s picture

Version: » 7.x-5.9

Just as an update:
My php5/cli had:
display_errors = On
changing it to:
display_errors = stderr
solved this

guilopes’s picture

the comment #15 solved my problem, thanks :)

luxpir’s picture

Comment #15 also solved it for me. Many thanks.

rambabburi’s picture

Where I need to put the above patch file?

I already in stalled Drush,if i execute the below command:

drush php-eval "var_dump(drush_shell_exec('curl --version'))";

i am getitng bool(false)