I use MingGW shell/MSYS to get access to the standard Unix tools (and a decent terminal/shell) on Windows. MSYS is much less intrusive than Cygwin ... Anyway, Drush doesn't work in MSYS because the lack of a which program. (In MSYS which is shell script.) In addition MSYS has tar.exe, not bsdtar.exe.

Finally, when downloading dev modules, Drush uses a question mark in the filename which is illegal on Windows. Replacing the question mark with a hash (fragment identifier) works equally well.

Patch coming up.


Status:Active» Needs review
new2.03 KB

Here's the patch.

Added: FYI: Replacing "which wget" with "wget --version" is consistent with the behavior of the wget package handler - see package_handler_validate in commands/pm/package_handler/wget.inc

Status:Needs review» Needs work

Most of the changes in this patch look good; however, I wonder about the change of '?date=' to '#date='. Does this URL just happen to work, or is it guaranteed to work? I would be inclined to keep the format of the download URL the same as it has been. Plus, we already have this in the code:

  // On Windows file name cannot contain '?'
  // See http://drupal.org/node/1782444
  $filename = str_replace('?', '_', basename($release['download_link']));

This should already handle the situation you're describing. If it does not, perhaps there is a better fix than using ''#' in the URL.

Status:Needs work» Needs review
new2.8 KB

Ok, the fix in #1782444: dev project update in Windows filesystem fails with md5 sum failure looks good, but it's not present in 7.x-5.8. (Looking at it I notice that the commit was done on the master branch, and not on 7.x-5.x. I'll comment in that issue pointing here.) Since the fix hasn't been applied to 7.x-5.x, I have included it in my updated patch - removing my change to the URL.

I also found one more issue when testing the site-install command - I needed to modify drush_has_bash. If you don't make this change to drush_has_bash, the testing for existing database fails since it tries to send the output to "/dev/null" (in stead of "nul"). The change could have been made directly in drush_bit_bucket, but since PHP doesn't run in MinGW/MSYS' bash shell I found it better to modify drush_has_bash. (PHP exec doesn't use bash, but cmd.) MinGW doesn't have PHP - it's coming from some kind of WAMP.

new2.4 KB

Argh, the patch contained a debugging statement that I forgot to remove - better now.

Status:Needs review» Needs work

Please apply your patch against the 'master' branch, not the 7.x-5.x branch. Thanks for your work here.

new1.88 KB

Another try - patch against the master branch now.

Status:Needs work» Needs review

Just updating the status (in case it wasn't obvious).

Just one remark related to Git for Windows (GfW). GfW uses MSYS so this patch is relevant for that project too. However, since GfW contains curl the problem with wget isn't present. I have tested Drush with my patch on GfW too in addition to pure MSYS.

Added: Sorry - I deleted comment 7. I forgot to update the status when posting this comment the first time. I then deleted the comment (which I have permission to because I work on documentation) to avoid one single comment for updating the status. It didn't work as smoothly as expected since this became comment 8 instead of 7.

Version:» 7.x-5.8
new5 KB

Another update to this issue - two new problems fixed. (The patch is now against the 8.x-6.x branch which isn't a choice in the version dropdown menu.)

1) ini files specific to Drush wasn't found in batch processes (when drush is calling itself) because MinGW paths was used in stead of Windows. Example below should make the problem clear

$ cd $HOME/.drush
$ pwd
$ pwd -W
$ cd /etc/drush
$ pwd
$ pwd -W

2) tar in MinGW only works with Unix style paths. (This could be considered a bug in MinGW since all/many other executables accepts both Unix style and Windows drive letter style paths.) Example illustrating the problem:

$ pwd
$ pwd -W
$ tar cf c:/Development/drush-git/docs.tar docs
tar: Cannot execute remote shell: No such file or directory
tar: c\:/Development/drush-git/docs.tar: Cannot open: I/O error
tar: Error is not recoverable: exiting now
$ tar cf /c/Development/drush-git/docs.tar docs
$ gzip c:/Development/drush-git/docs.tar
$ ls docs.tar.gz

Notice how gzip accepts the same type of path that tar fails on.

Please considering commit my work. It doesn't break stuff for Mac/Linux users and drastically improves the situatuon for Windows user who have "Git for Windows" or "MinGW shell".

While I'm waiting for progress on this issue, I can report one more issue/feature.

Since the PHP exec command use CMD (and not MinGW Shell/Bash), you can't use Unix like paths in aliases.drushrc.php.
    'root' => '/drive-letter/path/to/drupal'
must be replaced with
    'root' => 'drive-letter:/path/to/drupal'

I assume this could be documented in examples/example.aliases.drushrc.php, but that file is already rather long ...

Title:Improved support for MSYS/MinGW shellFigure out how to manage filesystem paths for MSYS/MinGW shell
Status:Needs review» Active

I confirmed that all tests still pass under Linunx under #9 and committed it on the 8.x-6.x dev branch.

I am still concerned about #10, and feel that perhaps the following perhaps should have been handled as a separate issue from the other changes:

+  // Convert destination path to Unix style for tar on MinGW - see http://drupal.org/node/1844224
+  if (drush_is_mingw()) {
+    $destination_orig = $destination;
+    $destination = str_replace('\\', '/', $destination);
+    $destination = preg_replace('$^([a-zA-Z]):$', '/$1', $destination);
+  }

My worry vis-a-vis this code and #10 is that it seems to me that it is unclear when a mingw users should use DOS-style paths, and when they should use unix-style paths. Note that paths that appear in a Drush alias file might be used with PHP exec, and they might be used with PHP functions. More discussion is needed on the topic of which paths will work in which call path, and how the Windows Drush user should be expected to manage path differences. I committed the code above along with the other changes, but I believe that more work is needed here. Ideally, Drush should always ask the user to specify paths in one format, and Drush should know how to convert back to the other style of path as needed. Alternately, since the "C:" format is fairly easy to detect, perhaps Drush could allow the user to specify paths in either format. In either event, Drush should convert paths to the correct format where needed. The snipped above in archive dump should be factored out into a utility function that does the correct transformation, and that API should be used wherever this transformation needs to be done.

Thx a lot for committing #9. If Drush 5.9 is coming (long) before 6.x, I would very much like this to be ported to 7.x-5.x. (I can do it, if wanted.) If you want more Windows users, you need Drush to just work in "Git for Windows" (which is a MinGW Shell).

I agree that the filesystem path handling is messy, but remember that it happes because tar.exe has a bug. This probably should have been separate issue. (I didn't really like the title change you made.) Anyway, I'll try to explain what the issue is (to other readers, Greg, you probably have understood it by now):

MinGW Shell doesn't include PHP - there is no PHP compiled for MinGW. You need to use PHP from a WAMP like EasyPHP. Hence when PHP calls exec, the programs are really executed in CMD, and all file paths in PHP code are resolved by CMD. Hence, Drush can never, ever resolve something like /home/user/whatever correctly. Drive-letter paths can be handled like my patch does.

So, to answer your question: In relation to Drush, a MinGW user should use the normal Windows path - for example in aliases.drushrc.php.

Title:Figure out how to manage filesystem paths for MSYS/MinGW shellDocument how to correctly format filesystem paths for Windows shells and insure existing usage is consistent

At a minimum, the code snippet I quoted in #11 needs to be abstracted. The issue here isn't porting, it's testing. Drush on Windows ostensibly works, or should work, under DOS, Powershell, Cygwin or MsysGit / MinGW, but there are still a lot of problems in all of these environments due to lack of tests and testing. Please take a look at the function drush_correct_absolute_path_for_exec() in includes/filesystem.inc. This might already solve the problem you are having, and might serve as a better replacement for the aforementioned code that I probably should have backed out before committing #9.

Documentation per #10 should be added to Drush somewhere to explain to folks how to format paths correctly. If the rule is 'always use C: format', that's pretty easy to explain. It looks like that's the assumption in the code currently.

If you don't like my title, change it to something that better describes what needs to be done here.

You are correct that I should have used drush_correct_absolute_path_for_exec instead of the two str_replace and preg_replace lines in the code you quoted in #11 above.

Version:» 7.x-5.x-dev
new5.5 KB

Here is a re-roll against 7.x-5.x.

Status:Active» Patch (to be ported)

Version:7.x-5.x-dev» 8.x-6.x-dev
Status:Patch (to be ported)» Active

cherry-picked 76ac249d3bc16b56ebe17ec547efb48de836827d from 7.x-5.x branch.

@vinmasaro this issue must stay "8.x-6.x active" since there's still work to be completed.

new846 bytes

Attached is a patch (against) 8.x-6.x that fixes the issue raised by greg.1.anderson in comment 11.

@jonhattan: What did that cherry-picked comment mean. (I know what cherry-picking is in Git, but not well enough to understand that comment apparently.)

Regarding the current topic in this issue - correct filesystem paths. Maybe this short statement would do?

In Drush config files always use normal Windows path. When invoking Drush (on the command line) use paths of your choice - either normal Windows path or paths matching your current shell (MINGW, CYGWIN).

Status:Active» Needs work

Does #18 fix all of the open issues remaining here? It would be good if the OP could confirm that #18 resolves his issues. If so, I think it looks good, with the only work remaining being to integrate the suggested documentation sentence into README.txt somewhere.

Regarding #17, Jonhattan backported the previously-committed fix from this issue to Drush 7.x-5.x. Since there were no substantial differences in the 5.x and 6.x branches prior to this change, git cherry-pick was all that was necessary to backport.

Does #18 fix all of the open issues remaining here? It would be good if the OP could confirm that #18 resolves his issues.

I think I am the OP ;-) Yes, all my issues have been resolved. (#18 was just to make the code better - functionally nothing changed.)

Status:Needs work» Closed (won't fix)
Issue tags:+needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.