drush should find the drupal root correctly, even when symlinks are in use.

I had already uploaded a patch that fixes this with less impact at http://drupal.org/node/599698#comment-2131418 before that issue got hijacked and this one created, although the title of this issue is more descriptive of my problem. Re-attaching that patch here, have been using it for several weeks now without issue. It fixes the problem without the recursive walk in the patch above.

Committed greg's patch since we do need to handle folks who call drush.php directly. I do that routinely:

alias drush='php -d error_reporting=E_ALL ~/contributions/modules/drush/drush.php'

This patch prevents Drush from finding a Drupal root on my sandbox. Here is the layout:

Drupal root is at /home/USER/workspace/drupal-6/

Site code is at /home/USER/workspace/sitename.6/

Site is symlinked in so /home/USER/workspace/drupal-6/sites/sitename.6 is a symlink to /home/USER/workspace/sitename.6/

I used to be able to cd to /home/USER/workspace/drupal-6/sites/sitename.6/ and Drush would walk up the current directory chain (not jumping to symlinks source destinations) and would find the drupal-6 directory. It would then correctly determine "sitename.6" as the active site, with no drushrc needed at all - I wrote this code specifically so it worked like this ;)

In other words this is the exact converse of the use case presented in #599698: Load a drushrc.php from cwd, which had the files stored inside the Drupal sites folder, and then a symlink out to the workspace. I think both are perfectly valid layouts, although I think mine is probably the more common, as it fits more naturally with Eclipse's workflow (and probably other project based editors) - the only way to replicate the other layout would be to create your project, close Eclipse, move the project, create a symlink back to where the project was and then restart Eclipse.

The only practical approach that comes to mind, (without adding restrictions or an obscure option) is simply to check using one approach (e.g. without link resolving) first and if nothing is found then check the other (e.g. with link resolving). The attached patch attempts this - I have tested with both layouts and it appears to work well, but a verification would be good.

The attached patch also fixes a separate issue I found with the original path in that it would break when relative symlinks are used, because readlink only returns the content of the link (e.g. "drupal-6/sites/sitename.6", or "../../sitename.6"), which are insufficient for Drupal roots. When I switched to using realpath it worked correctly however, because this always give a path from the filesystem root.

Seems reasonable to me. Lets give in the next couple of days soon so we can modify or commit this.

Thanks Greg!

The "break 2" certainly looks correct, and was just an oversight on my part.

The order of symlink/no-symlink search is not critical either way I think. It wasn't clear if the order affected your use case or not - if so, then it seems it would be fine to switch the order.

I doesn't really affect things, but the reasoning behind my suggestion - other than that I think it correlates to the more common layout - was that I think it maps to the users intention better, since they already chose to place themselves in the selected directory, rather than the "resolved" path, which they could have reached by doing "cd -P" rather than a straight "cd" if that was what they wanted.

seems like this is rtbc with or without owen's suggestion. i leave it to greg.

This doesn't work with a symlink in my root folder like this:

lrwxr-xr-x 1 joachim staff 40 26 Sep 08:27 m-alpha -> sites/localhost.module-lab.alpha/modules

~/Sites/module-lab/m-alpha joachim$ drush dl kitten
Project kitten (6.x-1.0) downloaded to                               [success]
/Users/joachim/Sites/module-lab/sites/all/modules/kitten.

In that case, I don't understand that this issue fixed.

If I do

$ cd sites/localhost.module-lab.alpha/modules
$ drush dl kitten

then it correctly downloads to the subsite.

I thought the point of this issue was to correctly handle a symlink that points to a sites folder.

@greg: sorry, but evern after some thinking i don't understand your special use case in #7:

For my somewhat odd use case, consider a local drupal installation with two instances of drupal, 'mydrupal.com' and 'dev.mydrupal.com'. Because these are d6 sites, they both need to be stored at 'sites/mydrupal.com'.

sorry id really don't understand - according to the docs you just create a 'dev.mydrupal.com' site - what am i missing?

(edit: this may go off-topic, feel free to pm me or ignore)

I think the issue was reopened here for the wrong reason. The original bug report was about finding the drupal root - Drush now does that fine - the problem mentionned here is more like #1158510: drush dl sends everything to sites/all even though i'm in sites/example.com that I just opened (and have a patch for sitting in my branches).