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

keltic’s picture

Upgrading to drush 5.1 resolved this issue for me.

moshe weitzman’s picture

Status: Active » Closed (duplicate)
sgwood’s picture

No, 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...

stewart.adam’s picture

I could reproduce this by running drush after changing directory ignoring case sensitivity:

cd ~/sites/drupal
drush status

^ fails, but this works:

cd ~/Sites/drupal
drush status

Just be mindful when typing paths! Tab autocompletion is your friend.

ohthehugemanatee’s picture

Status: Closed (duplicate) » Active

Re-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?

stewart.adam’s picture

I 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.

greg.1.anderson’s picture

It 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.

greg.1.anderson’s picture

Note 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.

escoles’s picture

As 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.

greg.1.anderson’s picture

Version: » 8.x-6.x-dev
Status: Active » Closed (won't fix)
Issue tags: +Needs migration

This 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.

Kristen Pol’s picture

I had this issue and seemed to jiggle drush into sorting itself out somehow. I think it went like:

  1. Lots of swearing
  2. Lots of googling
  3. Lots of swearing
  4. Realized that the error shows different cases for "Sites" and "sites"
  5. Found this post after more googling
  6. Tried renaming my "sites" directory to "Sites" (mv sites sites2; mv sites2 Sites) but no luck so moved it back
  7. Created an alias that used the Sites version and then the error flipped with sites=>Sites and Sites=>sites... o_O
  8. Removed alias and went to docroot and did "drush cc drush"
  9. Then all was well... weird