Just unpacked the rc1 version. For most drush commands it is failing trying to execute a hook in the coder module. The coder module is in my directory tree but is not enabled. If the module is not enabled then why are hooks being executed on the module? Since the module is disabled hooks should not be executed for that module. Since the module is disabled any drush commands for that module should not be available.

Setup was:

  729  ln -s /root/drush/drush.php /usr/local/bin/drush

Then to cd into the drupal root. No config file exists etc.

"drush status" works (dumps out status) and "drush" (no args) prints out the usage message. But every other invocation I've tried does this:-

host:/var/vhosts/www.7gen.com# drush info

Fatal error: Call to undefined function t() in /var/vhosts/www.7gen.com/sites/all/modules/coder/coder.drush.inc on line 10

Call Stack:
    0.0050      97916   1. {main}() /root/drush/drush.php:0
    0.0319     746860   2. drush_main() /root/drush/drush.php:30
    0.4253    2202388   3. drush_parse_command() /root/drush/drush.php:62
    0.4253    2202388   4. drush_get_commands() /root/drush/includes/command.inc:152
    0.4289    2269872   5. coder_drush_command() /root/drush/includes/command.inc:89

The other issue is why is the t() function missing.

Comments

reikiman’s picture

reikiman commented

FWIW doing the following is a workaround for the failure.

host:/var/vhosts/www.7gen.com# rm -rf sites/all/modules/coder/

Various drush commands work now. ...however...

a) I imagine Drupal programmers to frequently use t() and having t() unavailable inside a drush command might be inconvenient

b) to me it's a violation of the principle of least surprise that drush commands in a disabled module would be available

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Closed (works as designed)
grendzy’s picture

grendzy commented

FYI, the issue was resolved in #455722: use of t() in coder.drush.inc line 10 should be replaced with dt()

reikiman’s picture

reikiman commented

@grendzy, I disagree that the issue you point to resolves the issue I filed. It's good to know coder's bug has been fixed. The issue I filed was simply exposed by coder's bug.

I understand that @moshe weitzman says "by design" however as I said above it seems more than odd to me for disabled modules to be providing drush commands. e.g. the admin page doesn't show administrative choices for disabled modules. ergo why should drush show commands for disabled modules?

There must be some deep zen I'm not groking.

grendzy’s picture

grendzy commented

Since drush isn't a module, drush commands also need not be modules.

You can add a 'drupal dependencies' key with hook_drush_command(), if a command is non-executable without certain modules enabled. I posted a patch for coder: #471874: coder.drush.inc should declare coder as dependency

moshe weitzman’s picture

moshe weitzman commented

yes it is odd, and it is also by design. it is expensive to check which modules are enabled and which commands are "valid" so we just list them every command we can find on the `drush help` page. commands from disabled modules may not be executed though, as we do perform all validity checks in this case.

adding a dependency to coder module is not strictly needed and will not help.

grendzy’s picture

grendzy commented

adding a dependency to coder module is not strictly needed and will not help.

I see what you mean, the 'coder' command will still show up in the list even with the dependency. It will, however, provide a more informative error message when `drush coder` is run with the coder module disabled.

moshe weitzman’s picture

moshe weitzman commented

You should get just as informative a message without the dependancy. If you don't, then we have a bug.

grendzy’s picture

grendzy commented

Without dependency:
Drush command could not be completed.

With dependency:

Command coder needs the following modules installed/enabled to run:  [error]
coder.
The command 'drush.php coder block' could not be executed.

Is it supposed to do something else? The second seems a lot more useful to me, because it tells you why the command didn't run.