No it is not. As a matter of fact the Subsystem for UNIX-based Applications (SUA), formerly known as Interix, includes several GPL'd apps, so MS isn't per-se against the GPL.
Unlike Cygwin, this subsystem extends on the POSIX subsystem that was provided with previous Windows versions (I think up until including XP) and is an actual subsystem to Windows, just like the Win32 subsystem.
Admittedly the Win32 subsystem has a special stance in the system as it has privileged access to some resources, but in general the architecture of Windows allows for multiple subsystems to run in parallel. Allegedly the POSIX subsystem was originally included to satisfy some requirements for US government software purchases.
Cygwin, in many places mimics the behavior of old Interix (which used to be commercially available only in times of NT4 and 2000), but can for certain reasons not provide all the same semantics. IIRC Cygwin is actually based in the Win32 subsystem, while SUA is a subsystem in and of itself. I have no Cygwin handy, but some of the differences should be that Cygwin may or may not be able to handle case-sensitive file names - i.e. several different files in parallel, such as foo, foO and FOO in the same folder - although the NT platform and certainly NTFS is able to handle this. However, the Win32 retains case for all I know, but it doesn't care about it. SUA on the other hand does. You can also create files with a trailing dot (such as foo.) in SUA which you can't in Win32 (and likely Cygwin).
SUA, like Cygwin has the huge drawback of the performance penalty, though. I recently tried it on Windows 2008 Server R2 and it was rather sluggish when compared with Cygwin. Nevertheless alone the different semantics on the file system could provide an advantage, for example with the GNU Autotools, because they may rely on features (or rather semantics) only commonly found on unixoid systems that SUA faithfully mimics, but Cygwin cannot.
And of course Fran is right that you don't get a debugger plugin for VS with Cygwin. The rest, however, should be included also with Cygwin by means of the "package manager" during installation.
This error shows you couldn't connect to the server. That can have many reasons:
- a firewall blocking incoming connections to your server
- a firewall blocking outgoing connections from your computer
- ssh daemon on the server configured to listen on a non-standard port
- stopped ssh daemon
Since you can transfer files from your other computer I'd say you probably have a firewall blocking the connection. By the way... I supposed this host "test" is just a hypothetical example you used. Note it's IP address is not a valid local address (11.22.33.44), so if this message is real you should try using the server's IP address in place of "test".
Best Answer
The destination path looks wrong - to most unix shells the backslash is an escape character not a path marker, so I'm guessing the file has dropped into the SSH user's home directory with an odd filename.
IIRC copssh is based on cygwin, so what you probably needed to run is:
An alternatives to copying to a SSH service on the Windows machine is to use a GUI client like WinSCP on the Windows box to login to the Unix machine and pull the files over that way - though this is not suitable if you are trying to automate the process.
If you have privileged access on the unix machine (i.e. you are, or can become via sudo or similar, root) and have the relevant support installed you could just copy the files onto a Windows share. You don't say what Unix you are using. For Ubuntu and similar checking that support is present and installing it if not can be done with
sudo aptitude install smbfs, you can them mount a Windwos share with something likesudo mount -tcifs //11.22.33.44//sharename /mnt/tmp -ousername=WindowsUserName(where 11.22.33.44 is the IP address of the windows machine, depending on your network setup you may be able to refer to the machine by name rather than address). Once you've done that you can just use the basic file management tools (cp,mv, ...) to interact with that Windows share and callumount /mnt/tmpwhen you are done. You might want to choose a more meaningful mount point name than /mnt/tmp. You can leave the share mounted, of course, if the transfer of the data is to be automated/scheduled. This method does assume that the Unix machine can see the Windows machine's fileshares through any firewall arrangements that may exist between them.