As a developer, I want to run Drush commands as easily with ddev as without (with no quoting issues)

[damienmckenna]

Is your feature request related to a problem? Please describe.
Currently in order to run Drush commands you have to pass them through the exec system. This runs into problems in 1.8.0 due to the bash execution system as quotation marks and backslashes are mangled as part of the execution. This results in needing to do a really cumbersome combination of quotation marks and backslashes in order to run commands.

With a native system you can run Drush commands like this:
drush ev "cache_clear_all('something:*', 'cache', TRUE);"

The current DDEV-Local equivalent would be this:
ddev . drush ev "cache_clear_all('something:*', 'cache', TRUE);"

Unfortunately that will result in errors from the underlying system that handles the exec functionality because of unescaped characters.

There should be a way of running Drush commands with ddev that doesn't require either huge mounts of character escaping or ssh'ing to the web instance.

Describe the solution you'd like
I'd like to be able to run Drush commands as simply as I can with a local system so that I can do something like this:
ddev drush ev "cache_clear_all('something:*', 'cache', TRUE);"

Describe alternatives you've considered
I've attempted to work out the appropriate combination of backslashes and quotation marks to use, it turns into a PITA.

DDEV-Local is supposed to be aimed at making life easier, having to run ddev ssh doesn't match my concept of "easy" as it moves the user into the virtual machine, removing all of their local aliases, commands, etc.

Additional context
n/a

[rthideaway]

I know exactly what you're talking about. Eval commands with drush ev are difficult to execute. Here is an example of a command we execute on CircleCI during our build which just sets default mail system for Drupal 7 app:

ddev exec drush ev 'variable_set\(\"mail_system\",\[\"default-system\"\=\>\"DefaultMailSystem\"\]\)\;'

Doesn't look really nice. And it took some time to realize where is the problem and write it in a way it's executable.

[rfay]

You both know that drush runs on the host too right? Most commands work fine. For example:

rfay@rfay-mbp-2017:~/workspace/d7git$ drush ev 'variable_set("junker99","someval");'

rfay@rfay-mbp-2017:~/workspace/d7git$ drush ev 'print_r(variable_get("junker99")."\n\n");'
someval

[rthideaway]

Ah okay, it really works thanks to ddev_drush_settings.php, very true. One just needs to be in docroot.
Everything's fine for me! Sorry @rfay for false alarm.

Not sure about @damienmckenna, maybe he has a different kind of problem. Otherwise this can be closed.

[damienmckenna]

I understand that Drush runs via the host, I'd just prefer to be able to run drush commands locally like I can with other solutions.

[rfay]

The problem here is the args to drush, and of course adding bash interpretation into v1.8 has had side-effects like this one. Drush is behaving fine, but double-interpretation of the args by the host bash and the container bash are the source of the pain here. I wonder if there should be an exec command that does not use bash to interpret (as all exec commands were pre-v1.8 [I think]).

[damienmckenna]

Or could the exec function have some logic to adjust the rest of the string so the commands would pass through?

[rfay]

ddev v1.10+ (alpha already available) has a sample ddev drush command, would love if you'd try it out and see if it meets this need. It might still have double-bash-interp problems.

[rfay]

I closed #2027 as duplicate, but what it added to the equation was only adding the ddev drush command in Drupal and Backdrop projects.

[rfay]

The fundamental problem with this request is that quotes are interpreted first on the user's shell, before ddev could ever see them. And they're interpreted differently in different shells.

ddev used to not interpret via bash inside the container, and that led to its own amazing list of problems.

One path is to give the user the capability to choose when bash expansion happens inside the container. That would make it easier to solve the nastier problems.

[therobyouknow]

Solution for me was to escape each of the special characters, i.e. precede each of them with a backslash "".

So

ddev drush ev '\Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();'

Becomes:

ddev drush ev \'\\Drupal\:\:entityManager\(\)\-\>getStorage\(\"shortcut_set\"\)\-\>load\(\"default\"\)\-\>delete\(\)\;\'

And it works!

Used in this question/answer: https://drupal.stackexchange.com/questions/184495/config-import-error-these-entities-need-to-be-deleted-before-importing#comment370498_187368

[emb03]

I am finding it very hard to use drush and connect to the ddev database. I can't use drush cr or drush uli and the docs are scant on info. Is this not even possible? I installed Drush 10 using composer.

[rfay]

If you have a standard Drupal build, with "web" as the docroot, and the site already works with web access (ddev launch), and you did a ddev composer require drush/drush then it should work out of the box. On the other hand if you have drush installed somewhere other than vendor/bin/drush, or your composer.json is not in the root of the project where it would normally be, then you'll have to do a bit more work.

I should add that your question has nothing to do with what this issue is about - could you open a new one, or use one of the other support channels ?

[rfay]

In v1.19.0, ddev drush works without quoting issues. Thanks for the issue!