Commands fail on Windows remote (cygwin) from Linux host (Follow up)

[dmsmidt]

This is a follow up of #1788, which was repurposed to remove WinRS support.

So lets pick up with Drush 8.1.5 without WinRS:
The host is running Linux and the Target is running Windows with Cygwin.

In my aliases file I have the following (simplified):

$aliases['windows'] = array(  
  'root' => 'C:\Websites\SomeSite',  
  'uri' => 'http://www.somesite.com',  
  'os' => 'Windows',  
  'remote-host' => '124.123.123.123',  
  'remote-user' => 'Windows\\User',  
);

Previously (Drush 8.1.2) I had the drush @windows ssh command working.
Now even this doesn't work anymore (when root is specified), because the root path is wrongly formatted in the ssh command part: cd \''C:Websites\Somesite'\''.

Full error:

The filename, directory name, or volume label syntax is incorrect.
Connection to 124.123.123.123 closed.
An error 1 occured while running the command `ssh 'Windows\User'@124.123.123.123 'cd \''C:Websites\Somesite'\'' && bash -l'`

Previously (what worked) the path was formatted like this cd ""C:\\\\Websites\\\\Somesite"".

Other commands which now use SSH instead of WinRS are able to connect, but also have problems with the root.

The directory `C:\Websites\SomeSite` does not contain a valid Drupal installation

In debug mode I see that the path after --root= is similarly wrongly formatted as in the drush ssh command.

Am I correct to assume that only the drush @windows ssh command switches to bash at the remote side, but all other command just stay in the windows shell and call the Windows version of Drush?

[weitzman]

Yes, ssh command is a bit special. sql-cli and php commands are similarly special.

I tried a quick fix for this at #2381. Not sure if it will work. You will have to change Drush code on your source machine. Please let me know if this fixes it. If patching that code is too complex in your environment, just change your value of 'root to 'C:/Websites/Somesite' (note number and direction of slashes) and retry.

[dmsmidt]

Wow, that is quick. I checked out '2379-sitealias-windows' on my system and it works right away for commands like ssh, status, sql-dump, pm-list. I also tried enabling/disabling modules and that worked as well.

1. I even tried without the site alias option 'os' => 'Windows', and it still works. So why would I still need that?

2. Using the ssh command I'm sure I get into a bash shell (that is hardcoded). How about all the other commands? Or are they shell independant? In debug mode I still see Windows paths (Although now with forward slashes instead of back slashes, and Windows Git Bash also understands cd C:/Websites/Somesite and translates it to `cd /c/Websites/Somesite'.

3. sql-cli still fails, my connection is disconnected immediately.

4. sql-sync also fails with:

rsync: change_dir "/cygdrive/c/Websites/C:/Websites/Somesite/c:\websites/drush-backups/Somesite/20161007161320" failed: No such file or directory (2)

[weitzman]

1. That param is still used for escaping of command arguments. Arguments
   which have special characters (like paths) will benefit from that setting.
2. I don't know how this should work on Windows. Help needed. Post a
   --debug log so I can see the disconnect.

3/4. These fails are interesting. Could you please post logs with --debug.

[weitzman]

I just pushed a commit which attempts to clean up more path handling in sql-sync (particularly its backup handling in sql-dump). Please retry 4. with the latest commit.

[dmsmidt]

1. Ok, thanks.

2. I think I found it uses the Windows shell / cmd prompt.

3. Particularly interesting is that when I tried to capture the log in a file it did work!
   So drush @windows sql-cli fails with a direct disconnect and drush @windows sql-cli 2>&1 | tee /dev/null works. So getting a full log was a bit tricky. This is what I have: http://clipboard.space/clip/JB8aeOpWopuoz6ZObrw6

4. http://clipboard.space/clip/7BLwvXx9bxhJXP5z9OMW

(I just saw your extra comment, I'll try it, and let you know)

[dmsmidt]

I tried the new commit, a pity it still throws the same rsync error. Such a strange composed cygwin path..

[weitzman]

Just pushed one more commit for the sql-sync issue but its not likely to help on its own. If you can replace the drush on the remote with the new branch, thats awesome. I think it should fix the problem. If thats not feasible, you can workaround the problem by setting --target-dump option on the sql-sync call. The value should be a an existing temp dir like C:/tmp or somesuch.

[weitzman]

I merged that branch into master

[dmsmidt]

I appreciate the speed of resolving this issue(s). But can we re-open this, not all points are solved. Or do you want separate issues for that?

3. Do you also have a clue about the sql-cli disconnect (see earlier comment)?

4. Unfortunately I can't install composer on the Windows machine (no permissions). So back to your workaround.
   The '--target-dump' should be '--source-dump' in my case, because my source is the remote Windows machine. But, that option still didn't help me. I can see that the backup file is created in the given directory. But the rsync part goes wonky.

drush-git sql-sync @prod @self --source-dump=C:/Websites/tmp.sql
You will destroy data in secret and replace with data from ip/secret.
Do you really want to continue? (y/n): y
[ok] Starting to dump database on Source.
[notice] Initialized Drupal 7.50 root directory at C:/Websites/subdir/secret
[notice] Initialized Drupal site www.secret.com at sites/default
[notice] php.exe "C:\ProgramData\Drush\drush.php" --php=php.exe --backend=2 --root=C:/Websites/subdir/secret --uri=http://www.secret.com sql-query "SHOW TABLES" 2>&1
[notice] Command dispatch complete
Warning: Using a password on the command line interface can be insecure.
Warning: Using a password on the command line interface can be insecure.
[success] Database dump saved to C:/Websites/tmp.sql.gz
[notice] Command dispatch complete
[ok] Starting to discover temporary files directory on Destination.
You will delete files in /tmp/tmp.sql.gz and replace with data from 'DOMAIN\username'@IP:C:/Websites/subdomain/secret/C:/Websites/tmp.sql.gz
Do you really want to continue? (y/n): y
receiving incremental file list
rsync: change_dir "/cygdrive/c/Websites/C:/Websites/subdir/secret/C:/Websites" failed: No such file or directory (2)
sent 121 bytes received 128 bytes 166.00 bytes/sec
total size is 0 speedup is 0.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1650) [Receiver=3.1.2]
[error] Could not rsync from 'DOMAIN\user'@IP:C:/Websites/subdir/secret/C:/Websites/tmp.sql.gz to /tmp/tmp.sql.gz

In this server home is 'C:/Websites/' and the --root is 'C:/Websites/subdir/secret'.
It looks like at some point rsync tries to sync from this pattern: home+root+source-dump-path. Or is this really only testable with the latest master on the remote Windows machine? Note that the drush rsync command works, but I used a custom path-alias for it (%files' => '/cygdrive/c/Websites/sumdir/secret/sites/default/files/').

[weitzman]

3 Sorry, no idea.

4 Alas you will need new code on remote to make this work. You could run the composer install on another machine and use sftp/rsync/git to replace the drush code.

[dmsmidt]

I did some debugging for 3).

The problems is the env command. This program is in CoreUtils of GnuWin32 (backported and shipped with Cygwin), but it behaves a bit different on Windows causing ssh to disconnect.

So, Drush executes this command for a sql-cli:
ssh -t user@server 'env COLUMNS=140 drush --root=C:/Websites/subdir/somesite --uri=http://somesite.com sql-cli 2>&1' 2>&1.
However after the env command is done the prompt will be given back and ssh disconnects.
Remove the env COLUMNS=140 part and it works like a charm.

I researched (a bit) about how to do set the environment variable for one command the proper way in cmd on Windows. But, it is not so straightforward. So I propose to just remove that part for Windows. It workes fine enough without.

4. We don't have composer on the Windows remote, so I tried rsyncing a completed build, but I couldn't get it running before. Ah PHP version too low. I'll give it another go if and when the php version is more recent.

[weitzman]

Thanks for debugging that. I think that env call is coming from drush_build_drush_command(). The offending code is surrounded by drush_has_bash($os). It turns out I broke a function used there - drush_is_windows(). See my latest commit - c019ac5. Hopefully this fixes the problem.

Make sure you keep'os' => 'Windows' in your site alias.

[dmsmidt]

Jup that fixes 3). So that os setting is more important than only escaping 😄.

Unfortunately I won't be able to test 4) anytime soon. So I would say go ahead and close this.

Thanks a lot!