when i run an action from my local machine on a remote website (using aliases) drush automatically responds Yes to the confirmation question
e.g. when I disable a module:
boris@bobuntu:~$ drush -vB @remsup dis webform
Load alias @remsup [notice]
Begin redispatch via backend invoke [notice]
Initialized Drupal 6.20 root directory at /home/connexion/connexion.be/support [notice]
Initialized Drupal site support.connexion.be at sites/support.connexion.be [notice]
webform was disabled successfully. [ok]
Command dispatch complete [notice]
The following extensions will be disabled: webform
Do you really want to continue? (y/n): y
Backend invoke is complete [notice]
Drush doesnt stop at the prompt "Do you really want to continue? (y/n)" but continues and automatically responds "yes"
the same happens when i add the parameter "--no":
drush -vB @remsup en webform --no
the alias settings are:
$aliases['remsup'] = array(
'root' => '/home/me/support',
'uri' => 'support.example.com',
'remote-host' => 'example.com',
'remote-user' => 'example',
'db_url' => 'mysql://exampleman:tadida@localhost/support',
'path-aliases' => array(
'%dump' => '/home/me/temp/drushdumps/support.sql',
'%files' => '/home/me/support/files',
'%drush-script' => '/home/me/drush/drush',
)
);
Im using drush 4.4
Comments
Comment #1
greg.1.anderson commentedThis is as designed, and is probably "won't fix" for 4.x. However, once #1058874: drush_backend_invoke buffers output till end of command. Show progress. is committed, we could conceivably work on making remote commands interactive. In fact, I believe that most remote commands are interactive with that patch, the one exception being core-cli, which hangs up for some reason.
I think there is probably some more work to be done in the area of remote interactive commands, though, so I'm going to leave this active for 5.x for now.
Comment #2
batigolixok, got it
i couldnt find any post about this on drupal.org so i hope this issue serves other users that consider this a problem
the automatic confirmation got me in trouble sometimes because i use the pm-update command to check which modules are enabled on the remote site
anyhow, thanks for the quick reply
Comment #3
greg.1.anderson commenteddrush pm-list --status=enabledwill do the trick.I just noticed from your report above that the implicit --yes from --backend takes precedence over the --no from the command line. This is no good, and should be fixed in 5.x and 4.x.
Comment #4
greg.1.anderson commented--backend implies --yes, even if --no is explicitly included. This has very bad effects; for example:
drush @live pm-updatecode --noExpected: Print the module status display and abort. Actual: runs the pm-updatecode!
This patch insures that --no takes precedence over --backend.
Comment #5
webkenny commentedLooks good to me. I can confirm this works on two drush installs so far.
Comment #6
greg.1.anderson commentedCommitted. This is also important on the 4.x branch.
Comment #7
webkenny commentedFWIW, Greg, I tested this on a 4.x branch as well it seems to apply cleanly and work as expected. I assume nothing has changed in that area in the new version.
Comment #8
msonnabaum commentedBackported.
Comment #9
jonhattanI was getting notice
Use of undefined constant DRUSH_NEGATIVE - assumed 'DRUSH_NEGATIVE' environment.inc:685 [6.6 sec, 10.2 MB].Fixed in http://drupalcode.org/project/drush.git/commit/19b33c9
Comment #10
msonnabaum commentedGood catch. Backported.