Last updated 30 April 2016. Created on 14 October 2009.
Edited by krina.addweb, batigolix, greg.1.anderson, yurtboy. Log in to edit this page.

Below you find some examples of how to use the Drush sql-query (alias : sqlq) command.

Show information of user 1:
drush sql-query "SELECT * FROM users where uid=1"

Troubleshooting

error: system() has been disabled for security reasons

To resolve, go to your (local or global) php.ini and temporarily remove 'system' from the disable functions parameter:

Example:

Change
disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, shell, symlink
To:
disable_functions = show_source, shell_exec, passthru, exec, phpinfo, shell, symlink

Warning: this exposes some security risks, so there must be a better way to do it with PHP, without using the 'system()' function.

Using a custom php.ini
Please see the page Modifying the PHP or PHP configuration that drush runs under for instructions on creating a custom php.ini file for Drush.

Custom version of the php.ini file

You can use something like this to invoke a custom version of the php.ini file you want to use with Drush. The PHP command argument -c ini-file will allow you to specify a custom .ini file to use with Drush.

First, create a custom php.ini file in your drush installation, and ensure that the disable_functions entry permits the required functions (as specified above.) You can start with a copy of the default php.ini file used by your system, if you can access it.

Now, change your drush command alias (assuming you are using an alias) to include the -c path-to-custom-ini option, which will look something like:

alias drush='php -c path-to-drush/php.ini path-to-drush/drush.php'

Separate ini for drush

Hi, we think we may have a problem with how Drush updated some modules. Currently we have the following disabled:

proc_open, popen, curl_multi_exec, parse_ini_file, show_source.

Does Drush require any of these? We are running a separate .ini for Drush, but we don't want to give more privs than necessary because as we know Drush is really powerful. We have jailed ssh users and giving them Drush could elevate their privs higher than what they are allowed.

I looked around on the web, this is the closest to the answer I've gotten so far. Does anyone know of a list that will tell us for sure?

Update: We found out Drush needs popen.

Update 2: Drush specifically doesn't need parse_ini_file, but some modules (like ctools) do. We naturally turned this function off because it was in the default "disable classes" list for php. After digging around in the web awhile, I learned that there isn't a compelling case to turn this off. parse_ini_file does *NOT* parse the php.ini file, only .ini config files you set for your scripts. This function is really only a danger if someone gets access to your file system and reads a "secret" string or something of that nature. However, if they have access to your file system, you have much bigger problems anyway (like the fact that they're probably reading your settings.php file).

I think a lot of people get confused about parse_ini_file and ini_set / ini_alter. The latter 2 ARE dangerous because they allow individual users to alter how php behaves via a script or .htaccess file. It doesn't do any good to just restrict one, they are aliases and will do the same thing.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

mcurry’s picture

You can use something like this to invoke a custom version of the php.ini file you want to use with Drush. The PHP command argument -c ini-file will allow you to specify a custom .ini file to use with Drush.

First, create a custom php.ini file in your drush installation, and ensure that the disable_functions entry permits the required functions (as specified above.) You can start with a copy of the default php.ini file used by your system, if you can access it.

Now, change your drush command alias (assuming you are using an alias) to include the -c path-to-custom-ini option, which will look something like:

alias drush='php -c path-to-drush/php.ini path-to-drush/drush.php'

YMMV, of course. Cheers!

crimsondryad’s picture

Hi, we think we may have a problem with how Drush updated some modules. Currently we have the following disabled:

proc_open, popen, curl_multi_exec, parse_ini_file, show_source.

Does Drush require any of these? We are running a separate .ini for Drush, but we don't want to give more privs than necessary because as we know Drush is really powerful. We have jailed ssh users and giving them Drush could elevate their privs higher than what they are allowed.

I looked around on the web, this is the closest to the answer I've gotten so far. Does anyone know of a list that will tell us for sure?

Update: We found out Drush needs popen.

Update 2: Drush specifically doesn't need parse_ini_file, but some modules (like ctools) do. We naturally turned this function off because it was in the default "disable classes" list for php. After digging around in the web awhile, I learned that there isn't a compelling case to turn this off. parse_ini_file does *NOT* parse the php.ini file, only .ini config files you set for your scripts. This function is really only a danger if someone gets access to your file system and reads a "secret" string or something of that nature. However, if they have access to your file system, you have much bigger problems anyway (like the fact that they're probably reading your settings.php file).

I think a lot of people get confused about parse_ini_file and ini_set / ini_alter. The latter 2 ARE dangerous because they allow individual users to alter how php behaves via a script or .htaccess file. It doesn't do any good to just restrict one, they are aliases and will do the same thing.

Hope this helps save someone several hours of research!

~Crim

flickerfly’s picture

This makes turning off comments on all nodes for my blog nice and easy.

drush sql-query "update node set comment=0 where type like 'blog'";