Closed (duplicate)
Project:
Drush
Version:
5.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
27 Mar 2008 at 21:02 UTC
Updated:
15 Nov 2008 at 04:25 UTC
Jump to comment: Most recent file
Comments
Comment #1
webchickOh, I see. It's not required. I just get
which cascades into 20,000 errors.
Comment #2
webchickHrm. Well. This fixes it. No telling if it breaks anything else, tho.
But compare before/after the patch with E_ALL reporting going and you'll see what I mean.
Comment #3
webchickComment #4
webchickAnd in case you're too lazy to do that, here's what happens. ;)
So um. Yeah. Would be nice if it wouldn't do that. ;)
Comment #5
owen barton commentedI don't think there is a way to do it using $_SERVER from the command line, because Apache (which normally provides most of the $_SERVER variables) is not involved in the request at all.
You can do this in a fashion right now by adding the 'l' parameter to a drushrc.php file in the sites/mysitename.com directory (or any directory that you live in when you work on that site).
The way I think this *could* be done in a smarter way (and have been meaning to try for some time) is to check the current directory, and also each parent directory (in turn) for a settings.php, and then to try using the name of *that* directory as the domain, if no specific domain 'l' parameter is passed in from the command line. This way, you should be able to run drush from anywhere inside a sites directory (e.g. from a mysitename.com/modules/cck) without needing to specify 'l' at all.
The 2 special cases of 'default' and 'all' would need to be checked at all. I think 'default' should work fine (since it would use that site if you accessed Drupal through http://default), but 'all' would need a special check I think (probably just fail with a helpful error message for now).
Comment #6
moshe weitzman commentedJust set your l param in a drushrc.php and you never have to think about it again. takes 10 seconds. i'll look at patches for this, but my pain is long gone on this topic.
Comment #7
eyecon-1 commentedThe simplest and most flexible solution (for me) is a .bashrc function that includes a "for" loop. No sense encumbering a module.
Comment #8
moshe weitzman commentedComment #9
Dan_Hoey commentedThe "documentation" for drush is the output from
drush help, and that says that the-l <uri>;option is only needed in multi-site environments. Yet this obscure error message always appears if you omit the option, even fordrush help. I've got drush 5.x-1.3, and I don't see the cascading, but even one error message is a bug if there's no error.Comment #10
Dan_Hoey commentedOn further examination, I find that moshe has applied the patch in
drush-7.x-1.x-devanddrush-6.x-1.x-dev. So the bug is only indrush-5.x-1.x-dev, which doesn't have webchick's patch.Comment #11
moshe weitzman commentedWell, you probably don't have settings.php in the default directory. Thats what drupal does by default. If you stary from that, than you need to specify -l. You can specify it in drushrc.php so you don't need to ever think about it.
Feel free to suggest better wording in the docs.
Comment #12
Dan_Hoey commentedI've got
./sites/default/settings.php, is that what you mean? I still don't see howsettings.phpcould makedefine('DRUSH_URI', drush_get_option(array('l', 'uri'), FALSE));(in
./modules/drush/drush.phpin drush-5.x-1.3) setDRUSH_URIto something that makes$drupal_base_url = parse_url(DRUSH_URI);have a 'host' component.
Comment #13
moshe weitzman commented#334596: Improve root and uri detection logic and messages in drush.php