Search Results

Maybe there are better ways, but the following should work: drush user-add-role "power user" $(drush user-information [email protected] --field=name) You get the user name from the e-mail address …

The only solution I see is to write a little wrapper script that always calls drush with the --uri option, like: drush --uri $MY_SITE_URL_VAR $@ Recommended solution A much simpler solution is to use …

Hopefully, you should be able to discover which file/directory name is causing the problem, by making Drush print some debugging info: drush -d -d status …

It's the module that handles "libraries" dependencies - not Drush. AFAIK you can't force Drush to ignore hook_requirements implemented by the module in (the install file). … Some modules, for example Colorbox, provides a Drush command to download the missing libraries dependencies, but it's not automated. …

If you had use the correct term, you would have been pointed to for example the following question which has the info you need: drush sset system.maintenance_mode 0 …

This isn't a Drush issue. It's about the configuration of your shell. The file creation mode is controlled by the umask. …

The exit codes are defined in includes/drush.inc. Your logic seems sound, but I can't verify that is correct/always will work.

If drush pm-update, gives you the message "This codebase is assembled with Composer instead of Drush. [...]" you know that Drush uses the file. …

Anyway, replace PATH="$HOME/.composer/vendor/bin:$PATH" with PATH="/opt/drush-8.x/vendor/drush/drush:$HOME/.composer/vendor/bin:$PATH" assuming you may have other stuff in $HOME/.composer/vendor/ …

Either remove the user line from that file, or run Drush as another user than root (which might not have a .my.cnf file.) …

Read https://github.com/drush-ops/drush/issues/2367 …

The script must be executable: chmod u+x drush The script must be in the (executable) path. … Since it's not recommended to have the current directory in the path (for very good security reasons), the solutions is to call Drush as ./drush instead of just drush. …

Since drush pm-updatestatus is so noisy, the "Checking available update data" output is IMHO debug output that shouldn't be displayed, I often use drush pm-releases (rl) in stead. … Another work-around is to throw away the debug output: drush pm-updatestatus MODULE 2> /dev/null …

The Drush 9 documentation is pretty clear: Install Drush locally, in your Drupal site, using composer. You can install Drush Launcher in addition if you want it more convenient. … Without Drush Launcher, you can use the site local Drush be running vendor\bin\drush some-drush-option from your Drupal site root. No need to modify any paths. …

On the dev server you have the phar-installed global Drush 8 and the site-local Drush 9. … It might work to upgrade the phar-installed Drush 8 to 8.15, but why not use Drush Launcher (which is recommended) and install in globally instead of Drush. …