drush loads duplicate command files

this is a known issue. this only affects the listing of commands when you do a plain drush help. all other commands work as expected ... in order to make that command list very fast, we do not bootstrap drupal and instead just slurp up all command files we can find. if you have to bootstrap drupal to figure out which modules are active for the given site, you slow down a lot. i looked at this for a while and came up with the current approach. i believe all the maintainers were in agreement. i encourage folks to come up with patches that make us more robust to the issue described here but still keep command list very fast.

Yeah, we could bootstrap to DATABASE phase and then query system table. Would only be a tiny bit slower.

I'm encountering the same issue even without duplicate modules. Drush works fine from the root of a drupal install (ie, I can call drush status at the drupal root), but any drush commands that are directed at specific sites generate the following:

Fatal error: Cannot redeclare system_help() (previously declared in /Users/jeff/aegir/hostmaster/modules/system/system.module:47) in /users/jeff/aegir/hostmaster/modules/system/system.module on line 106

Call Stack:
    0.0008     721808   1. {main}() /users/jeff/drush/drush.php:0
    0.0094    2028528   2. drush_main() /users/jeff/drush/drush.php:40
    0.0493    5475048   3. drush_dispatch() /users/jeff/drush/drush.php:90
    0.0493    5477256   4. call_user_func_array() /users/jeff/drush/includes/drush.inc:23
    0.0493    5477504   5. drush_command() /users/jeff/drush/includes/drush.inc:0
    0.0503    5485944   6. call_user_func_array() /users/jeff/drush/includes/command.inc:289
    0.0503    5485976   7. drush_invoke() /users/jeff/drush/includes/command.inc:0
    0.0510    5488168   8. call_user_func_array() /users/jeff/drush/includes/command.inc:240
    0.0510    5488416   9. drush_core_status() /users/jeff/drush/includes/command.inc:0
    0.0510    5488416  10. drush_bootstrap_max() /users/jeff/drush/commands/core/core.drush.inc:363
    0.0696    7528344  11. drush_bootstrap() /users/jeff/drush/includes/environment.inc:252
    0.0697    7529488  12. _drush_bootstrap_drupal_full() /users/jeff/drush/includes/environment.inc:172
    0.0697    7570560  13. drupal_bootstrap() /users/jeff/drush/includes/environment.inc:721
    0.0749    7848192  14. _drupal_bootstrap() /users/jeff/aegir/hostmaster/includes/bootstrap.inc:989
    0.0809    8866568  15. _drupal_bootstrap_full() /users/jeff/aegir/hostmaster/includes/bootstrap.inc:1078
    0.1008   12086600  16. module_load_all() /users/jeff/aegir/hostmaster/includes/common.inc:2608
    0.1158   14280744  17. drupal_load() /users/jeff/aegir/hostmaster/includes/module.inc:14

Drush does not define system_help(); Drupal defines it at modules/system/system.module. Maybe this is an issue with Aegir?

I'm running through the same issue with 'drush provision deploy' and zengine on a drupal 5 site on aegir. Here's the link to the original bug I posted in provision module... http://drupal.org/node/673926

Can you itemize all the system.module files in your source tree. I can't fathom why there would be more than one but it seems you have that. Are you trying to override system.module by putting a copy in the sites folder?

Edit: This is a reply to #7.

Well, that is a little disappointing. The workaround in most cases is to make sure that drush does not see the same module twice (don't set -i too broadly, etc.); I suppose that what this means is that you just can't use provision deploy with any module that defines any hook that aegir uses. The former case is minor; perhaps the aegir conflict makes this more important?

I leave this for wiser minds to unravel. Maybe anarcat or adrian can provide a patch.

Can you itemize all the system.module files in your source tree. I can't fathom why there would be more than one but it seems you have that. Are you trying to override system.module by putting a copy in the sites folder?

Nope, I only have a single copy of system.module in the source tree, and it's in the default location -- I'm going to try to jump in with a debugger later to see where it's running into the problem, at least on my setup. The really odd part is that it is actually reporting the same file as the location of the redefined function.

I suppose that what this means is that you just can't use provision deploy with any module that defines any hook that aegir uses. The former case is minor; perhaps the aegir conflict makes this more important?

I'm not sure this is related to aegir, though: running drush dl [modulename] in a particular site's own directory doesn't load Aegir, does it?

Well, to answer a question you didn't answer first (as way of a preamble), drush will always call drush_drupal_version() for any command invocation, and drush_drupal_version does this:

require_once($drupal_root . '/modules/system/system.module');

This is the setup. The "require_once" means that if someone else comes along and does another "require_once", everything will be fine--maybe. I notice in your diagnostic message that the first time the path is mentioned, it is given as "/Users/jeff/...", and the second time it is "/users/jeff/aegir/...". Could it be that the difference in case between "Users" and "users" is subverting the behavior of "require_once" and breaking on your system, whereas it is working on everyone else's?

I notice that pm_module_manage does this:

  if (function_exists('module_load_include')) {
    module_load_include('inc', 'system', 'system.admin');
  }
  else {
    // Drupal5 only.
    require_once('./'. drupal_get_path('module', 'system') .'/system.module');
  }

Not likely to be your culprit, since you say it's happening for all drush commands, but it could be something similar to that, where the path called to require_once is coming out oh-so-slightly differently and causing the problem you're seeing. Just a theory.

To answer the question you asked, drush will include all of the drush.inc files it can find in all of drush's search paths, and all of the module search paths for any drupal site that it bootstraps, so this could have been a problem with Aegir if Aegir defined a function system_help(). That's not the case here, and I'm less certain on what code paths will be called in your circumstances, but it probably has something to do with something that happens in drush_bootstrap_site. Come to think of it, that's probably when drush_drupal_version() is called.

Anyway, if my theory is right, then your issue is unrelated to the problem reported by the OP of this issue. Good luck.

Thanks, greg -- I'll dig a bit deeper into this and make sure there aren't any oddball settings pointing to the case-insensitive version of Drush...

I'm pretty sure we can blame that case variation. I'm surprised so many people are running into this though. Maybe Aegir is lowercasing your paths somewhere.

After a lot of digging around, the case sensitivity DID prove to be the problem. I'd manually entered the local paths of a couple of Aegir platforms into the frontent using lowercase, and the drushrc.php files had been written out using those lowercase paths.

Fixing the lowercase instances in the drushrc.php files, as well as the vhost files that Aegir had output, fixed things on my end.

Thanks for the patience and the sharp eye.

Glad to hear that your problem was worked out.

Postscript for future skimmers: The problem described by the OP is different, and is still an issue.

I resorted to quickly switching the theme to garland on production (cringe) and doing the backup. Then deploying the staging site and switching back to the original theme. It's a not too pretty workaround, but it worked for me.

Will do. I'm taking a closer look this weekend and will open an issue for it where the details can be sussed out.

I CAN say beyond a shadow of a doubt that the drushrc.php file generated by Aegir (because I typed the pathname in lowercase, not because of an aegir bug) is the center of the rippling effect I saw. I'm not sure how reasonable it is to expect Drush to special-case around OS case sensitivity if it is *explicitly told* incorrect information...

subscribing...

+1 for #20. Clean. Fixes the problem. Works for me.

Looks like a good remedy to me. Committed.

Hi I'm getting the same error and can't apply the patch. This is my patch error.

patch < 644126_no_dupe.patch
patching file command.inc
Hunk #1 succeeded at 411 (offset -55 lines).
Hunk #2 FAILED at 435.
1 out of 2 hunks FAILED -- saving rejects to file command.inc.rej

My Drush Error is:

drush status

Fatal error: Cannot redeclare system_help() (previously declared in /var/www/pressflow/modules/system/system.module:47) in /var/www/pressflow/sites/all/modules/drupal-6.15/modules/system/system.module on line 106
Drush command could not be completed.

The patch is committed; you do not need to apply it. Start again with a fresh checkout of drush-HEAD and try to reproduce the problem again. If it persists, post your results here.

Same problem persists after checking out the latest drush-HEAD located at:

• http://ftp.drupal.org/files/projects/drush-All-Versions-HEAD.tar.gz

Error message is:

Fatal error: Cannot redeclare system_help() (previously declared in /var/www/pressflow/modules/system/system.module:47) in /var/www/pressflow/sites/all/modules/drupal-6.15/modules/system/system.module on line 106
Drush command could not be completed.

I'm on Amazon Web Service using the Project Mercury AMI (http://getpantheon.com/).

Drush is located at /opt

Symbolic link was created:ln -s /opt/drush/drush /usr/local/bin/

File "example.drushrc.php" was altered to "drushrc.php"

# Allow Drush to use 128 MB of memory. Use -1 for no limit.
ini_set('memory_limit', '128M');

// Drupal root directory to use.
$options['r'] = '/var/www/pressflow';

// URI of the drupal site to use.
$options['l'] = 'http://website.com/';

You have a drupal codebase inside sites/all/modules. Remove it.

Thanks that's very strange. I can't recall putting it there. Is that part of the Mercury AMI or just my gaff?

Unfortunately same error still occurs:

drush status

Fatal error: Call to undefined function user_access() in /var/www/pressflow/sites/all/modules/rdf/rdf.module on line 24
Drush command could not be completed.

These are the contents of my modules directory now after the Drupal Code Base was removed

ll
total 436K
drwxr-xr-x 6 root root 4.0K 2010-01-12 21:35 admin
drwxr-xr-x 9 root root 4.0K 2009-08-05 21:20 adsense
drwxr-xr-x 5 root root 4.0K 2009-04-05 18:00 advanced_help
drwxr-xr-x 2 root root 4.0K 2009-10-12 17:40 aes
drwxr-xr-x 5 root root 4.0K 2009-04-27 19:05 ajax
drwxr-xr-x 3 root root 4.0K 2010-01-15 02:10 ajax_register
drwxr-xr-x 6 root root 4.0K 2010-01-18 04:05 apachesolr
drwxr-xr-x 3 root root 4.0K 2009-07-31 12:15 auto_nodetitle
drwxr-xr-x 3 root root 4.0K 2009-12-14 05:20 backup_migrate
drwxr-xr-x 3 root root 4.0K 2009-08-26 00:03 backup_migrate_files
drwxr-xr-x 3 root root 4.0K 2010-01-18 22:20 block_class
drwxr-xr-x 2 root root 4.0K 2009-02-25 15:55 blockregion
drwxrwxr-x 4 root www-data 4.0K 2009-09-05 13:30 cacherouter
drwxr-xr-x 9 root root 4.0K 2009-07-29 11:30 calendar
drwxr-xr-x 5 root root 4.0K 2010-01-02 01:45 captcha
drwxr-xr-x 10 root root 4.0K 2009-12-30 00:02 cck
drwxr-xr-x 8 root root 4.0K 2009-05-15 05:45 charts
drwxr-xr-x 3 root root 4.0K 2009-09-27 00:04 collapsiblock
drwxr-xr-x 5 root root 4.0K 2009-06-02 16:55 contemplate
drwxr-xr-x 5 root root 4.0K 2009-09-01 02:40 context
drwxr-xr-x 14 root root 4.0K 2009-10-21 22:05 ctools
drwxr-xr-x 2 root root 4.0K 2009-04-14 09:45 cumulus
drwxr-xr-x 15 root root 4.0K 2009-09-16 12:15 date
drwxr-xr-x 6 root root 4.0K 2009-09-23 18:50 devel
drwxr-xr-x 3 root root 4.0K 2009-06-05 00:30 dhtml_menu
drwxr-xr-x 3 root root 4.0K 2009-06-13 19:25 email
drwxr-xr-x 5 root root 4.0K 2009-12-07 22:30 emfield
drwxr-xr-x 5 root root 4.0K 2009-08-29 00:09 event
drwxr-xr-x 3 root root 4.0K 2009-12-20 01:25 extlink
drwxr-xr-x 3 root root 4.0K 2009-11-18 23:08 extractor
drwxr-xr-x 6 root root 4.0K 2009-12-21 23:30 features
drwxr-xr-x 10 root root 4.0K 2009-11-09 22:41 feedapi
drwxr-xr-x 4 root root 4.0K 2008-10-19 20:20 feedback
drwxr-xr-x 7 root root 4.0K 2009-10-20 20:30 filefield
drwxr-xr-x 6 root root 4.0K 2009-12-02 21:35 geo
drwxr-xr-x 4 root root 4.0K 2010-01-20 01:40 geocode
drwxr-xr-x 2 root root 4.0K 2009-09-22 19:01 georss
drwxr-xr-x 3 root root 4.0K 2009-11-26 01:35 getid3
drwxr-xr-x 8 root root 4.0K 2009-03-03 20:50 gmap
drwxr-xr-x 4 root root 4.0K 2009-04-01 18:21 google_analytics
drwxr-xr-x 14 root root 4.0K 2009-11-08 15:10 i18n
drwxr-xr-x 6 root root 4.0K 2010-01-16 11:50 image
drwxr-xr-x 3 root root 4.0K 2009-04-17 18:16 imageapi
drwxr-xr-x 4 root root 4.0K 2009-08-19 21:11 imagecache
drwxr-xr-x 2 root root 4.0K 2009-01-05 05:05 imagecache_effects
drwxr-xr-x 4 root root 4.0K 2009-10-20 20:35 imagefield
drwxr-xr-x 7 root root 4.0K 2009-09-25 14:55 imce
drwxr-xr-x 2 root root 4.0K 2009-06-21 03:50 jquery_ui
drwxr-xr-x 4 root root 4.0K 2009-04-24 00:14 jquery_update
drwxr-xr-x 2 root root 4.0K 2008-04-14 17:05 jstools
drwxr-xr-x 6 root root 4.0K 2009-01-08 13:30 lightbox2
drwxr-xr-x 5 root root 4.0K 2009-11-05 04:15 link
drwxr-xr-x 9 root root 4.0K 2009-03-03 20:35 location
drwxr-xr-x 3 root root 4.0K 2009-10-16 15:11 logintoboggan
drwxr-xr-x 13 root root 4.0K 2009-11-13 19:16 messaging
drwxr-xr-x 6 root root 4.0K 2009-10-23 15:31 mimemail
drwxr-xr-x 2 root root 4.0K 2009-10-20 21:08 mn_about
drwxr-xr-x 2 root root 4.0K 2009-10-20 21:08 mn_channels
drwxr-xr-x 4 root root 4.0K 2009-11-19 16:19 mn_core
drwxr-xr-x 4 root root 4.0K 2009-10-20 21:08 mn_search
drwxr-xr-x 3 root root 4.0K 2009-11-19 16:19 mn_share
drwxr-xr-x 3 root root 4.0K 2009-11-18 23:08 mn_world
drwxr-xr-x 5 root root 4.0K 2009-08-17 14:06 mollom
drwxr-xr-x 4 root root 4.0K 2009-04-14 19:56 nicemap
drwxr-xr-x 4 root root 4.0K 2008-11-30 20:10 nice_menus
drwxr-xr-x 7 root root 4.0K 2010-01-12 01:05 nodewords
drwxr-xr-x 10 root root 4.0K 2009-11-13 19:16 notifications
drwxr-xr-x 8 root root 4.0K 2009-08-18 14:02 og
drwxr-xr-x 9 root root 4.0K 2009-12-26 23:45 openlayers
drwxr-xr-x 3 root root 4.0K 2009-11-23 23:06 page_title
drwxr-xr-x 14 root root 4.0K 2009-10-21 22:06 panels
drwxr-xr-x 4 root root 4.0K 2009-12-06 00:11 pathauto
drwxr-xr-x 4 root root 4.0K 2009-10-03 12:19 patterns
drwxr-xr-x 2 root root 4.0K 2008-12-15 05:55 pngbehave
drwxr-xr-x 2 root root 4.0K 2010-01-17 17:35 poormanscron
drwxr-xr-x 9 root root 4.0K 2009-10-15 23:50 print
drwxr-xr-x 4 root root 4.0K 2010-01-12 23:15 purl
drwxr-xr-x 7 root root 4.0K 2010-01-15 01:30 quicktabs
drwxr-xr-x 5 root root 4.0K 2010-01-18 05:30 rdf
drwxr-xr-x 4 root root 4.0K 2009-12-04 01:01 recaptcha
drwxr-xr-x 3 root root 4.0K 2009-12-20 21:31 sections
drwxr-xr-x 4 root root 4.0K 2010-01-13 05:15 seed
drwxr-xr-x 2 root root 4.0K 2009-08-05 14:47 signwriter
drwxr-xr-x 4 root root 4.0K 2009-11-26 09:16 simplenews
drwxr-xr-x 3 root root 4.0K 2008-10-18 15:50 simpleviews
drwxr-xr-x 3 root root 4.0K 2009-12-29 00:16 site_map
drwxr-xr-x 5 root root 4.0K 2009-10-21 18:17 skinr
drwxr-xr-x 3 root root 4.0K 2009-03-10 21:02 smsframework
drwxr-xr-x 11 root root 4.0K 2009-09-14 15:16 spaces
drwxr-xr-x 3 root root 4.0K 2009-11-19 16:26 stored_views
drwxr-xr-x 3 root root 4.0K 2009-01-27 21:45 swfobject_api
drwxr-xr-x 2 root root 4.0K 2008-02-17 19:10 table_altrow
drwxr-xr-x 3 root root 4.0K 2008-12-31 12:05 tagadelic
drwxr-xr-x 5 root root 4.0K 2009-12-17 12:16 taxonomy_xml
drwxr-xr-x 3 root root 4.0K 2008-04-03 19:55 themesettingsapi
drwxr-xr-x 3 root root 4.0K 2009-09-07 17:26 thickbox
drwxr-xr-x 8 root root 4.0K 2009-11-16 21:16 timeline
drwxr-xr-x 3 root root 4.0K 2009-06-01 22:31 token
drwxr-xr-x 3 root root 4.0K 2009-05-29 14:56 typogrify
drwxr-xr-x 5 root root 4.0K 2009-12-09 06:36 vertical_tabs
drwxr-xr-x 14 root root 4.0K 2009-11-10 23:26 views
drwxr-xr-x 4 root root 4.0K 2009-06-30 20:12 views_bonus
drwxr-xr-x 2 root root 4.0K 2009-11-18 23:08 views_modes
drwxr-xr-x 5 root root 4.0K 2009-08-15 18:05 votingapi
drwxr-xr-x 5 root root 4.0K 2010-01-01 17:31 weather
drwxr-xr-x 8 root root 4.0K 2010-01-24 00:17 webform
drwxr-xr-x 5 root root 4.0K 2009-06-10 01:56 wysiwyg
drwxr-xr-x 3 root root 4.0K 2009-06-11 06:06 wysiwyg_spellcheck
drwxr-xr-x 9 root root 4.0K 2010-01-07 21:20 xmlsitemap

Had this problem cause of the presence of the /drush directory inside my sites/all/modules.

I deleted it then it was good.

I must be having a different error because I delete the drupal core from my modules directory and I still get the error

Fatal error: Call to undefined function user_access() in /var/www/pressflow/sites/all/modules/rdf/rdf.module on line 24
Drush command could not be completed.

Thanks problem was resolved by upgrading to latest Mercury project AMI.

I'm having this error. I tried both 6.x-3.0-alpha1 and All-Versions-HEAD.

Fatal error: Cannot redeclare system_help() (previously declared in [path-to-drupal]/drupal/modules/system/system.module:47) in [path-to-drupal]/drupal/modules/system/system.module on line 106

As I understand it, the patch works and is inlcuded in HEAD already? So if I'm having this problemen, then it's not related to this thread? Should I open a separate issue?

In the browser the Drupal site works as usual.

I'm having the same problem, PHP 5.3 on OSX, Drush is latest HEAD as of this moment, site is using Acquia Drupal and has only 1 system.module file.
Error is:

Fatal error: Cannot redeclare system_help() (previously declared in /sites/clients/client/modules/system/system.module:47) in /Users/bbuckman/Sites/clients/client/modules/system/system.module on line 106
Drush command could not be completed.                                                                       [error]

(47-106 are the start and end points of system_help().)

Has this issue been fixed, moved to another thread, or abandoned?

Thanks!

This may be related to the way it parses the full path of the home directory.

My site is in ~/sites/clients/client which is really /Users/bbuckman/sites/clients/client

If I do drush status or drush status --root=/Users/bbuckman/sites/clients/client then it gives me the system_help() error.

If I do drush status --root=~/sites/clients/client, it treats it as if it's not a Drupal root at all, and shows me only 3 lines of Drush and PHP information (with no error). If I do drush sql-cli --root=~/sites/clients/client, it tells me it needs a higher bootstrap level.

So it's not working, because it doesn't recognize the Drupal root, but it also doesn't throw that error in that case. So the issue with trying to load system.module with different (but really the same) paths probably still applies.

subscribing

Subscribing

When I had this exact problem (MAC OSX 10.6.4) --> repairing permissions and verifying them
with a clean restart helped.

It was weird because I could use drush on a local install of the dev version of Drupal 7 Alpha 6...

But not on anything else.

I did try all kinds of swapping around (different drush versions mixed and matched with different drupal versions -- including different versions of drush make)

The only thing that I could get to work rock solid was a fresh repair of the OS and the current stable versions of Drupal and Drush.

Hope that helps others! :)

See also #861822: Add an option to sanitize email addresses and passwords from user table post sql-sync., which will change the way bootstrapping works in drush 4.x HEAD.

I have also run into this issue. To make it worse, I can't think of anything that's changed on my system to cause it (apart from shutting down my laptop at the weekend instead of letting it sleep as I normally do!)
Basically, drush isn't working at all, all of a sudden.

Symptoms:

• Drush works in a clean directory to download Drupal.
• As soon as a clean install of Drupal 6.17 or 6.19 is installed (I tried both), Drush fails to complete any command for the site.
• The error is PHP Fatal error: Cannot redeclare system_help() (previously declared in /Users/mcjim/Sites/drupal-6.17/modules/system/system.module:47) in /users/mcjim/Sites/drupal-6.17/modules/system/system.module on line 106
• If system_help is renamed (e.g. to xsystem_help()) Drush still fails, but with the error message referring to the renamed function.
• It appears that any command that boots Drupal fails.
• Drupal 7 is not affected.

This is on OSX 10.6.4 with PHP 5.3.1.
I've tried using all three downloads listed on the drush project page (3.3, 3.dev, HEAD): each one fails the same way.
Repairing permissions and verifying them with a clean restart didn't help.

Solution:

Downgrade PHP to 5.2 (I used MacPorts).

Irritating, though, as it was working previously with PHP 5.3.

This is a separate issue; you are seeing drush loading duplicate files from Drupal, not duplicate commandfiles.

If you wanted to do more investigation and open a new issue, the help would be appreciated.

I know it's a new issue, but getting the exact same thing (line numbers and all) in D6.19, for the record.

I ran into this issue on OSX, PHP5.3, Drupal 6.19. I updated from Drush 3.0 to Drush 3.3 and the issue resolved.

Spoke to soon. Error is occurring on OSX 10.6.4, PHP 5.3, Drupal 6.19, drush 6.x-3.3.

Fatal error: Cannot redeclare system_help() (previously declared in /Library/Webserver/Documents/drupal6/modules/system/system.module:47) in /Library/WebServer/Documents/drupal6/modules/system/system.module on line 106

I note the case-sensitive paths in OSX WebServer vs webserver. Looks like drush is thinking it's a new file.

Hmm, I've been swapping my site alias from a D5 to D6 instance during the upgrade process using drush all the way. I think drush (or something) is caching the path. Invoking drush in a fresh Terminal session gave no error.

@jonathan_hunt: your error in #45 include two distintct paths to system.module (WebServer / Webserver). Please read #11, #15, ... #42 and please let's open a new fresh issue with all relevant data.

By the way, if this is hapenning in updatecode, #921116: drush updatecode should fork to a backend process to avoid problems will fix this also.

When running drush from Terminal in osx ensure that the directory path you are in is case-correct. For example, if you run drush in ~/sites/drupal when your path should be ~/Sites/drupal you will get this error:

Fatal error: Cannot redeclare system_help() (previously declared in /path/to/home/sites/drupal/modules/system/system.module:47) in /path/to/home/Sites/drupal/modules/system/system.module on line 106

Terminal will not force you to use the correct case when you cd into your drupal directory.

djroshi! Thank you 1 million times. #48 Solved my problem...

@djroshi's solution resolved this issue for me as well. I had a symbolic link pointing to an incorrectly cased path. I remade the link, this time with the path case correct for all directories, and Drush worked fine. Using: OS 10.6.4; PHP 5.3, Drush 3.3, Drupal 6.19

Hmmmm. Doing the opposite of @djroshi's solution resolved this issue for me (OSX 10.6.4, PHP 5.3, Drupal 6.19, drush 6.x-3.3 and HEAD).

I had a symbolic link pointing to a correctly cased path. Doing the following repeatably causes the error:

cd /Users/james/path/to/site; drush status

Changing the case of /Users to the incorrect lowercase fixed the issue. I.e. the following worked:

cd /users/james/path/to/site; drush status

I've had "drupal6-local" and "drupal6-local-new". Changing dash to underscore (drupal6_local) resolved this issue for me.

@djroshi thanks! this solved my problem perfectly.

Although I could remove the Drush error when the working directory is set to the Drupal install I'm interested in (using the correct case for the path - as discussed in previous comments), I still get the problem using a Drush alias (where the path case is correct). Problem first started after an upgrade to 4.2; tried upgrading to 5.0-dev and same problem. Reverted to earlier release but problem will not go away, so not entirely sure what caused the problem, but Drush aliases are currently unusable.
One point to note: I only get the error on D6 alias sites. D7 is fine with Drush.

Please open a new issue and follow the reporting guidelines at the top of the form if you do not resolve this on your own.

A bit more head scratching, I found that the problem was down to Drush (CLI) loading PHP5.3, whereas my server/site is running PHP5.2 - a MAMP config issue discussed at #973710: Drush assumes php 5.3 on MAMP when it shouldn't.

Two options:

1. Ensure site/server is configured to use same version of PHP as the Drush CLI
2. Tweak Drush iaw http://drupal.org/node/973710#comment-3717520. A little uncertain about impact on Kittens for this though

Anyway, for the benefit of Googlers, the duplicate command loading problem with Drush aliases (specifically the Fatal error: Cannot redeclare system_help() (previously declared in /modules/system/system.module:47) in //modules/system/system.module on line 106) has now gone away as soon as MAMP and Drush are using the same version of PHP and same php.ini (which you can check with drush status).

Don't think it warrants a fresh issue, although - given the popularity of MAMP - not sure if a little comment needs to be added to readme.txt...

If you are using MAMP/MAMP PRO you should note that Drush will attempt to load the most recent version of PHP. You may encounter problems with Drush if you configure MAMP to use one of the older versions available in your MAMP stack. Please see http://drupal.org/node/973710 for more information

I'm running Snow Leopard and I've been using drush without problems for a long time but today I noticed this problem. I'm not sure why it had never happened before, I haven't changed anything.

Anyway, I read #48 but didn't want to rename my personal directory (I have my sites in /Users/alexis/sites) so I just start my drush commands with:

drush -r /users/alexis/sites/sitename ...

Works for me.

Do I understand this problem correctly... In drush 4, it was perfectly acceptable to have the same module defined in multiple locations, since drupal is smart enough to load modules from folders in a predefined order and will only load enabled modules. In drush 5, for speed reasons, we no longer rely on that logic and load all modules that are found. The result of this is that modules that exist in more than one place (profiles/XXX/modules or sites/all/modules or sites/example.org/modules) will cause drush to break?

This is fairly major for us if this is true. We manage a large installation where one of our strategies is to allow some sites to use newer module versions than those in the install profile by installing modules in their sites folder.

Regardless of whether the command was drush help foo or , commandfiles are loaded via <code>_drush_add_commandfiles, which will mark every commandfile name found (e.g. "foo" from "foo.drush.inc") in a list, and therefore should not load the same commandfile twice. Drush-5.x is actually smarter about bootstrapping commandfiles than Drush-4.x.

If anyone is having problems with this, they should open a new issue with complete debugging information. What I said in #42 still stands -- the "fix" suggested in #48 is for a different problem than what you're worrying about in in #58.

deleting...having trouble reproducing.

Noting that the problem with case-sensitivity still exists for me. It seems to be a particular issue on OSX, because it has a case-insensitive filesystem that masquerades as a case-sensitive filesystem. I use Drush on a lot of development sites locally, but on one of them I kept getting this duplicate loading issue. In my case the specific error was:

Drush command terminated abnormally due to an unrecoverable error.                                                                                           [error]
Error: Cannot redeclare drupal_set_content() (previously declared in /Users/ohthehugemanatee/Sites/foo/includes/common.inc:41) in
/users/ohthehugemanatee/Sites/foo/includes/common.inc, line 48

Fatal error: Cannot redeclare drupal_set_content() (previously declared in /Users/ohthehugemanatee/Sites/foo/includes/common.inc:41) in /users/ohthehugemanatee/Sites/foo/includes/common.inc on line 48

(this is D6 btw)

Note the different casing for "/users" in those paths. This is fixed using @jrsinclair's solution: "cd /users/ohthehugemanatee/Sites/foo ; drush status" works fine.

I have no aliases, there's nothing I can think of or grep for that ever references the directory path... so I don't know where Drush would get the impression that it should scan both versions.

@ohthehugemanatee I agree - this does appear to be an OSX-specific issue. Is it worth creating a separate issue to indicate this, as this thread seems to have wandered all over the place?

On another note, do you have multiple versions of PHP on your system as indicated in #56? Is it possible that this is the source of the error for most people?

I was having the same problem with Drush in OS X until I tried @djroshi solution (#48).

deleting the drush folder from sites/all/modules fixed this for me too.

I guess since you download it from Drupal.org, the assumption is it should go in the modules folder. After I deleted the folder, drush works fine.

Here's the error I was getting:

A10319:thr andena01$ drush sql-cli
PHP Fatal error:  Cannot redeclare sql_drush_help() (previously declared in /usr/local/lib/drush/commands/sql/sql.drush.inc:10) in /Users/andena01/thr/thr/sites/all/modules/drush/commands/sql/sql.drush.inc on line 26
Drush command terminated abnormally due to an unrecoverable error.                                                                                                                                                                                       [error]
Error: Cannot redeclare sql_drush_help() (previously declared in /usr/local/lib/drush/commands/sql/sql.drush.inc:10) in /Users/andena01/thr/thr/sites/all/modules/drush/commands/sql/sql.drush.inc, line 26

same as #64. delete the drush on sites/../modules fixed this for me too. (drush was downloaded there by mistake)

For me, on Mac, this worked

mv sites Sites2
mv Sites2 Sites
cd [my project]
drush status (still see error)
mv Sites sites2
mv sites2 sites
cd [my project]
drush status (all better)

stumbled over this too. dazzling to me: i was using a faulty (wrong cases) symlink for months and drush was working smoothly. so i just rejected the idea my symlink could be the cause of trouble. only when i read this post https://www.drupal.org/node/1727314 of Mojomamdd i began to think about the case being a possible source of my problem. well, it was. thx to all of you!

#61 worked for me. Issue was 'cd ~/sites' vs. 'cd ~/Sites' before running drush from drupal directory.

drush development has moved over to github yall. also, there has been a lot of work on this lately against drush 6.x-dev (on github!). try it with that.

#48 solved it for me

#48 also worked. i was in ~/sites/projectname instead of ~/Sites/projectname

OMG, #48 just saved what little hair I had left from pulling it out due to this error. Thank you Thank you Thank you!!!!!

#48 fixed my problem. Using drush 7.0-dev. Drupal 7.36. @djroshi is THE Man!

I had this issue (and still do in some ways). I realized that I had not correctly matched capitalization on my httpd.conf file with the actual directory/documentroot that I was loading virtual sites from. OSX doesn't care about capitalization, but Drush/Drupal do. I had to make sure that users was Users, etc...