aliases.drushrc.php not working inside a drupal root or site.

Well, there's a chicken-and-egg problem here. Aliases are only loaded on-demand, for the most part; the sa command is the notable exception, as it will load all of the alias files it can find. However, alias files for a 'sites' folder are not searched unless that site is bootstrapped, or an alias for that site is mentioned.

For example, I have a file /srv/www/dev.greenknowe.org/sites/greenknowe.org/peer.alias.drushrc.php. It contains:

<?php

$aliases['peer'] = array (
  'remote-host' => 'reetstreet.com',
  'remote-user' => 'publisher',
  'type' => 'live',
  'uri' => 'http://greenknowe.org',
  'root' => '/srv/www/drupal',
);

[Edit: Note that you should not define 'type' in your site alias; it interferes with pm-list. I renamed this to site-type.]

drush sa @peer prints nothing; it cannot find the peer alias. drush @gkdev sa @peer on the other hand will print the above alias definition, because adding "@gkdev" before the command bootstraps to the gkdev site. Similarly, drush rsync @gkdev @peer will work, because the peer alias will be locatable once the @gkdev alias is referenced. drush rsync @peer @gkdev also works, because rsync preflights the destination alias (if it can) before it looks for the source alias.

The above should also work if you identify your site with -r and -l, or if you cd to your sites folder, but I just tried that and it doesn't work -- so there's your bug. I'll fix it.

Do you think that the drupal root folder should also be added to the alias search location when a site is bootstrapped? That wouldn't be hard to add at the same time.

This patch fixes the bug described in #1 and also adds the drupal root of any bootstrapped site (or the drupal root specified by a lone -r) as a valid location to find alias files. It also includes the /path/to/root/@sites fix.

Committed.

Thankyou so so much for this!
I spent too many hours last week trying to restructure my various drush settings files (currently scattered across half a dozen accounts and servers) to deal with the updates that had stopped all my 'local' in-site-folder peer-alias settings from working. Now that the current working site dir is scannable again, my 'peer' configs (or equivalent) Are back in action! *phew*.
From gregs explanation about the boot order I'd seen before, I thought this was going to be a "won't fix"

I also like the look of the new(?) '@self' handle. I see good things happening there. I had to jump through all sorts of hoops to make that work in my own code.

I am happy today!
... now to throw out several pages of work-around code I wrote last week using dir scans and symlinks to get the old behaviour back

:-B