Installing drush in $HOME/.drush can cause policy.drush.inc to force updatedb to abort mysteriously

Please follow the submission guidelines described here: http://drupal.org/node/add/project-issue/drush

It looks like you have set $options['n'] = TRUE; in your drushrc.php, or something along those lines. The following may help you diagnose whether this is the case or not:

drush @yoursitealias ev 'print_r(drush_get_merged_options());' 

I just had the same problem. Here's the updb portion of the output. I got this both times I ran drush up (first upgrading my modules, and then drupal core).

The following updates are pending:

 captcha module                                                                                  
 6202 - Implementation of hook_update_N()  Add a CAPTCHA token column to captcha_sessions table. 


 creativecommons module        
 4 - description not available 


 invite module                                                                             
 203 - Update variable names to use role id instead of translated role name.  @see #322748 


 notifications_ui module                    
 6001 - Disable cache in subscription block 


 privatemsg module                                                 
 6200 - Add {pm_disable} table.                                    
 6201 - Change schema to allow other recipients than single users. 
 6202 - Remove duplicate entries in {pm_index}.                    
 6203 - Add primary key to {pm_index}.                             


 privatemsg_filter module                         
 6200 - Add hidden flag and create inbox tag.     
 6201 - Add inbox tag to existing inbox messages. 


 rules_forms module                       
 6001 - Update the module's weight to 20. 


 user_relationships_api module                                                                                         
 6102 - Implementation of hook_update_N().  Update 6102 adds the column is_reciprocal to the {user_relationship_types} 
 table                                                                                                                 
 6103 - Implementation of hook_update_N().  Update 6103 adds the {user_relationship_type_roles_receive} table          


Do you wish to run all pending updates? (y/n): n
drush: Aborting.
Command dispatch complete                                                                                      [notice]

Here's the output of drush_get_merged_options():

Array
(
    [drush-make-update-default-url] => http://updates.drupal.org/release-history
    [v] => 1
    [structure-tables] => Array
        (
            [common] => Array
                (
                    [0] => cache
                    [1] => cache_filter
                    [2] => cache_menu
                    [3] => cache_page
                    [4] => history
                    [5] => sessions
                    [6] => watchdog
                )

        )

    [skip-tables] => Array
        (
            [common] => Array
                (
                    [0] => migration_data1
                    [1] => migration_data2
                )

        )

    [config-file] => /home/ed/.drush/drushrc.php
    [context-path] => /home/ed/.drush/drushrc.php
    [php] => /usr/bin/php
)

I remember now that I saw this same behavior a few days ago on another site, and running update.php afterwards worked (I didn't capture any output from that drush run though).

Same problem here, even with -y ...

Here is the output of drush @ilww-home updatedb:

[16:43][ilwwtest:~]$ drush -y @ilww-home updatedb
The following updates are pending:

googleanalytics module
6300 - Try to update Google Analytics custom code snippet to async version.
6301 - Upgrade "User roles" tracking to custom variables.

Do you wish to run all pending updates? (y/n): n
Aborting. [cancel]

I never get a chance to answer the prompt.
And here is the output from drush_get_merged_options:

[16:49][ilwwtest:~]$ drush @ilww-home ev 'print_r(drush_get_merged_options());'
Array
(
[uri] => ilww.ilwwhome.net
[root] => /home/mysitehome/drupal_root
[db-url] => mysqli://mydbusername:mydbpassword@localhost/mydbname
[databases] => Array
(
[default] => Array
(
[default] => Array
(
[driver] => mysql
[username] => mydbusername
[password] => mydbpassword
[port] =>
[host] => localhost
[database] => mydbname
)

)

)

[name] => @ilww-home
[php] => /usr/bin/php
)

Try with drush-HEAD and this patch.

Guessing; theoretically, this patch should not help, because DRUSH_AFFIRMATIVE and DRUSH_NEGATIVE are set during bootstrap as follows:

  drush_set_context('DRUSH_AFFIRMATIVE', drush_get_option(array('y', 'yes', 'b', 'backend'), FALSE));
  drush_set_context('DRUSH_NEGATIVE',    drush_get_option(array('n', 'no'), FALSE));

Thus, these values should be set to either TRUE or FALSE. You might have to step through the code to solve this one; I cannot reproduce it.

Oh, I think I solved it. Try this:

drush @ilww-home updatedb --token=secret

That should work for you. You must pay me $0.25 to find out why that works. Just kidding. This is a good brainteaser. For some reason, you have the example policy.drush.inc file in a location where drush is including it. This might happen if you had --include=/path/to/drush/examples defined, but per your call to drush_get_merged_options() you do not, so you must have copied policy.drush.inc to $HOME/.drush, or maybe you put your whole drush folder in $HOME/.drush. (Not a good idea!)

I think I deserve my $0.25. :P

The warning in examples/policy.drush.inc was only being printed in --debug mode. (You should follow the issue reporting guidelines.) I committed to HEAD a change to this file to make the warning print out even in lack of -v and -d.

@greg - nice detective work. Unfortunately, we are going to be seeing more of this in the issue queue. It just happenned to me. I got on a shared server that only had drush3 and decided to get a drush4 for myself. Look where it ends up:

weitzman@drushci:~$ drush dl drush-7.x
Project drush (All-versions-4.2) downloaded to                       [success]
/home/weitzman/.drush/drush.

I don't think changing drush3 is going to help much since the many folks who are avoiding drush4 will avoid 3.4 as well.

Ah ha. You are right. I am responsible for drush going to $HOME/.drush as shown above :(. it's fixed now, but this bug will live on for a good time to come; we do need some remediation.

1. For people who update to new code, I suggest skipping the "examples" folder when searching for command files. You can still include the examples explicitly via --include=examples (that is, we skip folders names "examples" inside the search path, but it does not matter if the word "examples" appears in any part of any of the command search paths).

2. For people who are running drush-3.x, or drush-4.0 thru drush-4.2 and type "drush dl drush" to get the latest copy of policy.drush.inc in $HOME/.drush, I suggest further modifying the warning message to point the reader back here.

3. For people running older versions of drush (as above), and drush itself is in $HOME/.drush, there is no fix, because we cannot make any changes (by definition). Therefore, I suggest we add a FAQ about updatedb not running, point the reader to this issue, and further advise that they delete or rename policy.drush.inc in their drush installation's examples folder.

The enclosed patch does #1 and #2; I have not yet done #3.

Here is the patch promised in #9.

An alternative would be to comment out the code in policy.drushrc.php. Thats why including example.drushrc.php is not hurting us. Seems like a more robust solution.

I think #10 is more robust, because it guards against people who have old copies of drush hanging around in $HOME/.drush.

Example sequence of events (executed over a span of time)

drush dl drush
mv $HOME/.drush/drush $HOME/.drush/drush.bak
drush dl drush

Older versions of drush do not back up drush when you dl a new drush, so I think the above may be common.

Regarding disabling the policy, maybe we could also demo an updatedb init hook that set drush_set_option('token', 'secret'); to both re-enable updatedb and show the use of init hooks?

Overall, though, I think that we should exclude examples per #10, because there will be other examples showing up there over time, and I think it's too much to always be thinking about how the examples might harm active use of drush when stored in $HOME/.drush...

Makes sense. Lets commit #10. We might also consider banning /examples when searching for aliases, drushrc, etc.

Committed #10, including excluding examples when searching for aliases. Drush does not search deep for drushrc, so no change there. #12 not done.

Oh yes, this should be ported too. And maybe after it's committed to 4.x, perhaps it should be ported to 3.x as well...

Backported to 4.x.

Cool.

3.x is in deep freeze. won't commit there so status is back to fixed.