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.
I develop locally on OSX and place all my sites in ~/Sites
In one of my alias files I included the local root
as /Users/shawn/sites/my_project/public_html
I didn't have any issues before Drush 5.x.
With Drush 5.0 I received the error (D6.24)
Drush command terminated abnormally due to an unrecoverable error. [error] Error: Cannot redeclare drupal_set_content() (previously declared in /Users/shawn/sites/my_project/public_html/includes/common.inc:47) in /Users/shawn/Sites/my_project/public_html/includes/common.inc, line 54
Once I changed my alias root
to /Users/shawn/Sites/my_project/public_html
(uppercase S) things worked great.
Now this issue could very well be works as designed
but since this used to work in previous Drush versions I thought I would report it.
Comments
Comment #1
keltic CreditAttribution: keltic commentedUpgrading to drush 5.1 resolved this issue for me.
Comment #2
moshe weitzman CreditAttribution: moshe weitzman commentedComment #3
sgwood CreditAttribution: sgwood commentedNo, this problem is not resolved in Drush 5.1.
I have a fresh install of Drush via Pear on OSX.
The error does not apear when calling Drush on
fresh install of D7 however the
"Error: Cannot redeclare drupal_set_content()"
apears with a Drupal 6.22 installation.
Edit:
Moved my drupal folder from the MAMP standard folder
/Applications/Mamp/htdocs/
to
~/Sites folder and drush worked fine.
My System:
OSX snow
drush version 4.6-dev
Drush installed with this tutorial:
http://www.lullabot.com/articles/installing-php-pear-and-pecl-extensions...
Comment #4
stewart.adam CreditAttribution: stewart.adam commentedI could reproduce this by running drush after changing directory ignoring case sensitivity:
^ fails, but this works:
Just be mindful when typing paths! Tab autocompletion is your friend.
Comment #5
ohthehugemanatee CreditAttribution: ohthehugemanatee commentedRe-opening - what's this supposed to be a duplicate of? I don't see any other tickets that are about the same issue, except maybe the tail end of #644126: drush loads duplicate command files, long after it was closed and got to rambling on side issues.
This is an important issue for anyone who develops on OSX. HFS+ is case insensitive, but it acts case-sensitive. And this causes drush to load all its command files a second time and error out.
For example, I develop in ~/Sites/sitename . ~ is aliased to /Users/ohthehugemanatee . Intermittently my drush craps out on a site, until I cd to /users/ohthehugemanatee/Sites/sitename . I have no idea why it's a problem with the capital in /users/ and not in /Sites/ , but there it is.
Are there possibly some assumptions that Drush can make about the structure of a single drupal install? Like maybe get the path of common.inc, and use that for a case-sensitivity test?
Comment #6
stewart.adam CreditAttribution: stewart.adam commentedI believe that the trouble area here is that even if you can determine that paths are not case sensitive, it doesn't do you any good. For example: /Users/foo/SITES, /Users/foo/Sites, /user/foo/sites and /UsErS/foo/SItEs are all valid paths, but only one of those is "correct". As far as PHP is concerned, they're all the same. realpath() doesn't return /Users/foo/Sites, it's happy with whatever case you put into it.
Comment #7
greg.1.anderson CreditAttribution: greg.1.anderson commentedIt would be helpful if someone who is running on a case-insensitive filesystem could roll a patch to solve this problem. It would probably be sufficient to convert paths to lowercase in command.inc when checking for duplicate commandfiles. You would have to be careful to only lowercase paths used in comparison to avoid breaking Drush on systems with case-sensitive filesystems.
Comment #8
greg.1.anderson CreditAttribution: greg.1.anderson commentedNote that per #644126-61: drush loads duplicate command files, this problem often arises because Drush takes the path from the cwd, which might not have the same case as the path in the filesystem. I do not think that my suggestion in #7 is sufficient to fix this problem; when Drush pulls the path from the cwd, it is probably necessary to retrieve the same path from the filesystem, so that the case of the characters in it can be corrected.
Comment #9
escoles CreditAttribution: escoles commentedAs a workaround pending an actual patch, I've found that the following works for me:
cd to root (actually, account root is usually sufficient) and then cd back to the directory where you need to be, taking care to use the case shown in Finder.
It can be a nuisance, but it always resolves this issue for me.
Comment #10
greg.1.anderson CreditAttribution: greg.1.anderson commentedThis issue was marked
closed (won't fix)
because Drush has moved to Github.If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to
closed (duplicate)
.Please ask support questions on Drupal Answers.
Comment #11
Kristen PolI had this issue and seemed to jiggle drush into sorting itself out somehow. I think it went like: