Without this patch:

$ drush help blah
PHP Fatal error:  Call to undefined function drupal_bootstrap() in /home/ga/local/drush/includes/environment.inc on line 835
Drush command terminated abnormally due to an unrecoverable error.
Error: Call to undefined function drupal_bootstrap() in
/home/ga/local/drush/includes/environment.inc, line 835

With this patch:

$ drush help blah
Invalid command blah.
An error occurred at function : drush_core_help

The new implementation is simpler; it just bootstraps to DRUSH_BOOTSTRAP_SITE+1, which is as far as you need to bootstrap to bring in commandfiles. At this bootstrap level, all commandfiles are included, not just enabled commands. This is the same behavior as 'drush help' (w/ no command name). It would be slow to hide the disabled commandfiles; I think it's good like this.

CommentFileSizeAuthor
drush-help-cmd-bootstrap.patch1.82 KBgreg.1.anderson

Comments

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
commented
Status: Needs review » Reviewed & tested by the community

Showing help for commands in disabled modules is fine, but it's annoying to show 'command not found' when trying to run it --perhaps a separate issue.

moshe weitzman’s picture

moshe weitzman commented

The behavior in this patch changes for some commands. Namely, if we are in a drupal site and request help for a limited bootstrap command like core-rsync, then we bootstrap all the way to SITE+1 instead of bailing at DRUSH_BOOTSTRAP_DRUSH.

I just noticed that drush_print_help() bootstraps up to DRUSH_BOOTSTRAP_DRUPAL_SITE so the slowdown above is moot.

I forget what the +1 is for in SITE+1?

greg.1.anderson’s picture

greg.1.anderson commented
Status: Reviewed & tested by the community » Fixed

Regarding #1, we could avoid that by just taking off the drush_set_error at the end, and maybe replace it with a print or a log statement. The way it is right now is more consistent with drush command conventions, so I left it as it is, but I'm not opposed to making a change here.

There did not seem to be any need for SITE + 1; this was left over from the old algorithm in help. I took off the +1, and it still works fine.

drush_show_help does not bootstrap if it can find the command name among the commands available at the BOOTSTRAP DRUSH level. However, this is unnecessary, because as you mentioned, drush_print_help invariantly bootstraps to SITE, but I did not change drush_show_help anyway.

You are right that the algorithm is different now; previously, drush_show_help would bootstrap as far as the command said it needed to, but this was irrelevant, since the command is not running in drush_show_help. Now we only bootstrap as far as we need to for the help command, which is SITE.

Committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.