Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Drush was unable to download the Colorbox plugin to [error]
sites/all/libraries
This should be working, but it isn't and I don't see why. I tried playing around with the drush script, but it just doesn't seem to execute the download part
// Download the zip archive
if (!drush_shell_exec('wget '. COLORBOX_DOWNLOAD_URI)) {
drush_shell_exec('curl -O '. COLORBOX_DOWNLOAD_URI);
}
I leave this one for frjo since he created the script.
Comment | File | Size | Author |
---|---|---|---|
#11 | colorbox_drushunzip.patch | 675 bytes | aufumy |
#6 | colorbox_drush_dependency_check.patch | 674 bytes | frjo |
Comments
Comment #1
frjo CreditAttribution: frjo commentedI have only tested the Drush command on Mac OS X and Debian GNU/Linux.
What OS/Distro are you using when you see this problem?
Comment #2
jdwfly CreditAttribution: jdwfly commentedUbuntu 9.04 and Drush 3.0.
I am running it as my user as normal and I have write privileges to the directories. I can't think of any other reasons why it doesn't work.
Comment #3
frjo CreditAttribution: frjo commentedPlease run the Drush command with the debug flag.
That should give you some good hints why it's not working.
Do you have wget or curl installed? Or both?
Comment #4
jdwfly CreditAttribution: jdwfly commentedI'll give that a shot and I do have both wget and curl installed. I can manually download it using wget or curl like the script does.
Comment #5
jdwfly CreditAttribution: jdwfly commentedunzip wasn't installed. It definitely won't work without that being installed. Probably should have some documentation added somewhere that states requirements for the drush script. By default unzip isn't installed in a Ubuntu server.
Comment #6
frjo CreditAttribution: frjo commentedWhat do you think of adding a dependency check in the command itself?
Could you check if this works as it should in stock Ubuntu?
Comment #7
hutch CreditAttribution: hutch commentedPatch inserts fine. I'm not sure what 'stock ubuntu' is, I recently did an install of ubuntu 10.4 and as part of the install (expert mode) you get some options, which type of server you want eg ssh server, web server, database server, samba server and so on. I think it is reasonable to expect a sysadmin to ensure that certain packages are there such as wget, curl, rsync, ssh server and client, zip, unzip, bzip2, gzip, make, patch, perl etc etc. Ubuntu 10.4 server installed more by default than Debian 5 netinstall, my usual platform but you should check irrespective of distro.
Having said that I think the patch should go in anyway. I would haved used 'which unzip' but it may well be that 'type -P unzip' (which gives identical results) is more cross-platform. If anyone knows more speak up!
Both work on ubuntu, debian and OSX, that's all I have access to ATM, I will find out how the BSDs handle this from a friend.
EDIT:
Both work on FreeBSD and will likely work on openBSD and netBSD. Both commands appear to be generic bash. Other shells may/will do things differently, you can't cover them all.
Comment #8
frjo CreditAttribution: frjo commentedThanks for testing this so thoroughly. I have committed it to 6-dev now.
I prefer to use "type" since it's a Bash built in command and not an external process like which.
Comment #9
hutch CreditAttribution: hutch commentedMy BSD friend says
The "type" command is built into shells other than BASH (it's definitely in CSH).
So 'type' is probably the most likely to work in different shells.
I've not really looked at drush include scripts before, interesting.
Comment #10
frjo CreditAttribution: frjo commentedDrush has a good API making it very easy to add commands like "colorbox-plugin". Got the inspiration from the "solr phpclient" command.
Comment #11
aufumy CreditAttribution: aufumy commentedI am not able to use this, eventhough unzip is installed.
I had to reverse the operator. It may be that on success drush_shell_exec returns 0?
Comment #12
frjo CreditAttribution: frjo commentedaufumy, what environment are you running Drush in?
On success drush_shell_exec('type -P unzip') returns 1 on my systems (Debian/Linux and Mac OS X/BSD).
Comment #13
aufumy CreditAttribution: aufumy commentedI am using Ubuntu:
Linux FOO 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 22:02:19 UTC 2010 i686 GNU/Linux
According to the drush inline docs (in includes/drush.inc):
Comment #14
frjo CreditAttribution: frjo commentedIf you execute "type -P unzip" on the command line what result do you get?
The documentation in drush.inc seems to need correction.
Comment #15
hutch CreditAttribution: hutch commentedThere is a difference between the way a *nix shell program and PHP usually return their exit code.
Most shell programs return an exit code of 0 to indicate success and 'type' is no exception. Failure would return a non-zero exit code, 1 in the case of 'type', which also prints the path to STDIN on success. In a shell script you can collect the exit code (with $?) and check that the command succeeded.
Here is a snip of shell script:
Most PHP functions are designed to return TRUE or 1 (or some content) on success and FALSE (which is empty or 0) on failure.
I haven't tested it but
drush_shell_exec('type -P unzip')
would return 1 or TRUE or the path to unzip, it's a PHP function
Hope this clarifies things a bit
Comment #16
heavy_engineer CreditAttribution: heavy_engineer commentedHi, I also have this double negative thing going on - ubuntu 10.4, Drupal 6.16, colorbox latest dev. If i change line 19 from
to (notice its now checking if drush_shell_exec returned anything other than a zero)
drush_shell_exec returns a 0 according to http://drupalcontrib.org/api/function/drush_shell_exec - although looking at the code for drush_shell_exec, i fail to see how it can return 1 (might be my unfamiliarity with the module). But it looks to me that the drush function cant return anything but zero (line 410 drush/includes/drush.inc)
Personally i'd expect it to work how hutch described it. I've quickly searched on the drush issue queue for drush_shell_exec but cant find anything. I'll dig around and see if im just not reading it right before opening an issue on the drush queue.
Comment #17
hutch CreditAttribution: hutch commentedLooking at the code for function drush_shell_exec()
drush_shell_exec() returns TRUE on success,
return ($result == 0);
would resolve to TRUE or 1if $result is 0. $result is the exit code from exec() which in turn gives the exit code of the *nix command
so
is correct
Comment #18
frjo CreditAttribution: frjo commentedsteev_initsix and aufumy, if you execute "type -P unzip" on the command line what result do you get?
Comment #19
jdwfly CreditAttribution: jdwfly commentedI don't seem to have this issue (double negative) but with Ubuntu 9.04 I get this from the command-line...
Comment #20
aufumy CreditAttribution: aufumy commentedfrjo, sorry for the delay, I get:
/usr/bin/unzip
Comment #21
frjo CreditAttribution: frjo commentedThere seems to be a difficult to track down problem with the check for unzip.
What do you think about simply removing it? Instead we could add something like this to the final error message for faild downloads.
"Drush was unable to download the Colorbox plugin to @path. Make sure you have wget or curl and unzip installed."
To the README we can add.
You need to have the following installed for this command to work:
* wget or curl
* unzip
Comment #22
aufumy CreditAttribution: aufumy commentedreplacing
if (!drush_shell_exec('type -P unzip')) {
with
if (!drush_shell_exec('type unzip')) {
works for me
I added some debug statements to drush_shell_exec(), and when using 'type -P unzip', the $result would be 127 instead of 0. Also the foreach ($output as $line) would show
-P: not found
unzip is /usr/bin/unzip
whereas with 'type unzip', the $result would be 0. The foreach ($output as $line) would show just
unzip is /usr/bin/unzip
Comment #23
frjo CreditAttribution: frjo commentedI have committed aufumys suggestion in #22 to 6-dev, simply removing "-P" from the type command.
Comment #24
frjo CreditAttribution: frjo commented