Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I thought this was a problem with ACLs (#1158474: drush dl doesn't support ACLs), but actually, the problem is that --destination is a bit dumb:
anarcat@marcos:id.orangeseeds.org$ drush dl xrds_simple --destination=modules
Destination directory modules is not writable. [error]
... but this works:
anarcat@marcos:id.orangeseeds.org$ drush dl xrds_simple --destination=$PWD/modules
Project xrds_simple (6.x-1.0) downloaded to [success]
/var/aegir/clients/anarcat/id.orangeseeds.org/modules/xrds_simple.
Can we safely assume that paths are relative by default? :)
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1158490_relative_dest.patch | 932 bytes | anarcat |
| #2 | 1158490_relative_dest.patch | 954 bytes | anarcat |
Comments
Comment #1
anarcat CreditAttribution: anarcat commentedOkay, the issue here is that drush changes directories at some point before those checks and we end up at the drupal root, so that directory doesn't exist...
Comment #2
anarcat CreditAttribution: anarcat commentedComment #3
anarcat CreditAttribution: anarcat commentedthis is cleaner
Comment #4
msonnabaum CreditAttribution: msonnabaum commentedThe patch looks fine, although I can't seem to replicate the issue. From a drupal root, setting the relative path to "modules" is working just fine for me…
Comment #5
anarcat CreditAttribution: anarcat commentedi am running this from within the site-specific directory, try:
Comment #6
msonnabaum CreditAttribution: msonnabaum commentedSo drush treats the path as relative to the drupal root, which I guess could be confusing.
I'm curious what others think about this one as I've never really perceived this as a bug.
Comment #7
anarcat CreditAttribution: anarcat commentedOkay, I really thought this was a bug more than a feature, but if you want to put it this way - i want to change this feature. :P
I personally feel this feature is just a coincidence.
Comment #8
greg.1.anderson CreditAttribution: greg.1.anderson commentedOnce you are in "drush mode", all paths are by default relative to the drupal root of the site you are operating on, not the cwd. I tend to think that it would be better is drush presumed all relative paths (in cli args) were relative to the cwd, just like all other bash commands. I think it would be better if drush followed the standard, but it might be kind of difficult to change now.
I am kind of reluctant myself to change the standard to cwd-relative for dl, and leave it Drupalroot-relative for all other commands, though.
Comment #9
anarcat CreditAttribution: anarcat commentedWhat other commands are non-standard? Maybe we can fix this all in one swoop...
Comment #10
greg.1.anderson CreditAttribution: greg.1.anderson commentedThere are multiple ways to change this.
Drush changes the cwd to the drupal root as soon as it bootstraps to that level. This affects not only args, but also any filesystem access done by the drush command. If we changed this, we would break a lot of code; it would make for a rather painful migration, and people would need to either special-check the drush major version or have multiple implementations of their drush command. Not a good option.
Second, we could add metadata to drush help to tell what type options and args were, and fix up any that were marked as 'paths' to be relative to the cwd. Commands would then be inconsistent until everyone added the metadata to help. Maybe not a good option.
Third, we could add a new util function to convert path args to a full path. We could essentially run these through the same process that rsync paths go through, so that you can say things like
@somesite:pathor%files/subfolder, and so on.We would be inconsistent until everyone started using the new util function, but maybe it would not be so bad. We could fix up drush core in one swoop, and wait for everyone's contrib commands to catch up. I don't have a good measure of how many commands have args that are file paths.
Comment #11
anarcat CreditAttribution: anarcat commentedI believe it is bad practice to chdir() within functions, in general. It can be compared to using globals - you never know when they are changed and how.
So ideally, I would first problem #1 you describe: don't chdir() at all, but I understand how this could break things.
#2 and #3 seem to go together and seem to be a less disruptive workaround.
Note that right now, things *are* inconsistent, if only with regards to the shell. Take this as an example:
Now, I understand that for people that are very used to that paradigm, this can seem intuitive, but for newbies, it is very confusing. Heck it was confusing to me and I've been using drush for more than 2 years...
Also, from what I understand, Drush 5.x is a good time to make such changes. We are making a major upgrade, and things are going to break. I at least expect Aegir 1.x to not be compatible with Drush 5.x...
Comment #12
jonhattanA reason for drush to change the cwd to the drupal root is that in D6 (and below) this was a common practice:
require_once './includes/path.inc';. Drupal 7 define and use DRUPAL_ROOT.Comment #15
moshe weitzman CreditAttribution: moshe weitzman commentedNot much interest.