Yep, rxvt is dead. Use mintty instead: native Windows UI with context menu and options dialog, Unicode support, xterm compatibility, transparency. No X required.
You can greatly reduce the need for (mental and actual) path conversion by installing Cygwin into C:\. It's not officially recommended, but it actually works rather well. This way, you also get Windows path completion, e.g. C:/W followed by TAB will complete to C:/Windows, because bash completion ignores the C: bit. Windows programs do generally accept forward slashes in paths (and Cygwin programs usually accept backward slashes too, but bash won't complete those). Also, you can type something like '\bin\ssh server' into the start menu's run box, because C: is implicitly assumed.
With andLinux you have to go through the Linux boot process. Windows files have to be accessed through network shares. User accounts are separate. Windows and andLinux processes live in two completely separate environments, which means you can't combine tools through pipes and such. And it's more resource-intensive due to having to duplicate a lot of kernel-level functionality.
Don't get me wrong, andLinux is great technology, lighter than a VM, and the right tool if you're looking for maximum Linux compatibility. But claiming that it's more seamlessly integrated into Windows than either Cygwin or SFU is a nonsense.
Re:Recommended alternative terminal program?
on
Cygwin 1.7 Released
·
· Score: 1
urxvt or xterm if you want to run X, mintty or puttycyg if you don't.
Re:I wonder if Cygwin really has much of a future
on
Cygwin 1.7 Released
·
· Score: 2, Informative
Cygwin 1.7 does support case-sensitive filenames. See the User's Guide on how to enable it: http://www.cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive
It's also had various other improvements in terms of POSIX compatibility, for example, characters not allowed in Windows filenames can now be used in Cygwin. Another one is that mount points are now stored in/etc/fstab rather than the registry. See the What's New section for lots more improvements: http://cygwin.com/cygwin-ug-net/ov-new1.7.html
The Cygwin developers do have an official Linux compatibility goal, and fixes are going in all the time, but of course it's never going to be perfect, partly due to limitations of the underlying platform, and partly due to lack of (wo)manpower.
Re:Did they simplify fork()?
on
Cygwin 1.7 Released
·
· Score: 2, Informative
I don't really know the details, but the possibility of using the underlying NT calls to implement fork has been discussed a lot on the Cygwin mailing list, and the conclusion was that it won't work for Win32-level processes. Dropping down into a separate subsystem like SFU would require a major redesign and would break binary compatibility for everything as well as source compatibility for Cygwin programs that use Win32 themselves, e.g. rxvt or mintty.
Good points about avoiding fork where possible. spawn() is another way to do that.
How exactly can andLinux be described as less convoluted than either Cygwin or SFU? Instead of just the C/POSIX libraries, you also get most of a Linux kernel sitting on top of the Windows kernel.
Re:Does this do something SFU doesn't?
on
Cygwin 1.7 Released
·
· Score: 2, Informative
Things that Cygwin does better than SFU (as in what's on offer from MS. Dunno about community projects on top of that.)
- The latest version is available for all Windows (>=NT) variants, not just Enterprise and Ultimate.
- It's more compatible with GNU/Linux extensions (since SFU is not aimed at that).
- It's open source with open development, short release cycle, and responsive mailing list.
- Package system. (It's no apt-get, but it does its job, including dependency resolution and updates.)
- Bigger, more recent choice of packages. For example gcc, is 4.3 vs. SFU's 3.3.
- Bash and zsh.
- A usable default shell configuration. The arrow keys don't even work correctly in SFU's default ksh setup. (It's as if MS deliberately try to scare people off Unix.)
- A choice of terminals to replace the awful Windows console.
Also, what do you base your claim of SFU's better Windows integration on? Since Cygwin's based on the Windows API rather than being confined to its own subsystem, it can offer features like/dev/clipboard or/proc/registry, and it allows programs to mix POSIX and Win32 calls.
Finally, Cygwin 1.7 does also support case sensitivity on NFS and on NTFS volumes that have that feature enabled.
Re:is the library compatibility problem fixed?
on
Cygwin 1.7 Released
·
· Score: 1
Yep, a scheme for keeping processes using different Cygwin DLLs out of each other's way has been implemented. Just don't expect them to interact with each other, e.g. you can't send signals from one Cygwin sandbox to another. That's why the best approach still is to have only one Cygwin DLL on your system.
Cygwin can't use the NT fork support, because it's implemented on top of Win32, and NT's fork does not support Win32 DLLs.
Obviously that is a significant disadvantage, particularly during fork-heavy 'configure' runs, but there are also advantages that approach too, e.g. it allows things like/dev/clipboard for accessing the clipboard and/proc/registry for accessing the registry. It also means that Cygwin programs can mix POSIX and Win32 calls, so when porting from Unix to Windows you can take a gradual approach, or just port the UI only.
MinGW does not have a bash shell, because it provides nowhere near the level of Unix compatibility required for bash (as that's not the aim of the project).
There is an MSYS version of bash, but MSYS in fact is a (more or less unmaintained) fork of Cygwin 1.3.
Re:I was never really impressed
on
Cygwin 1.7 Released
·
· Score: 2, Informative
Good post. Regarding the last point about the default console, Cygwin ships with a number of replacement terminals: (u)rxvt, xterm, mintty. Mintty in particular provides a native Windows interface with Unicode support and does not require an X server. More at http://mintty.googlecode.com/
I think the Unicode and internationalization support is the most important improvement in 1.7, making it much more useful for people who need more than ASCII. There's been a lot of under-the-hood work to convert the Cygwin internals from using Windows "ANSI" APIs to Unicode APIs. Cygwin's filesystem will automatically translate between Windows filenames, which are encoded as UTF-16, and POSIX filenames, which are encoded as UTF-8 or whatever other charset you might have selected.
Slashdot Mirror
Yep, rxvt is dead. Use mintty instead: native Windows UI with context menu and options dialog, Unicode support, xterm compatibility, transparency. No X required.
You can greatly reduce the need for (mental and actual) path conversion by installing Cygwin into C:\. It's not officially recommended, but it actually works rather well. This way, you also get Windows path completion, e.g. C:/W followed by TAB will complete to C:/Windows, because bash completion ignores the C: bit. Windows programs do generally accept forward slashes in paths (and Cygwin programs usually accept backward slashes too, but bash won't complete those). Also, you can type something like '\bin\ssh server' into the start menu's run box, because C: is implicitly assumed.
Don't get me wrong, andLinux is great technology, lighter than a VM, and the right tool if you're looking for maximum Linux compatibility. But claiming that it's more seamlessly integrated into Windows than either Cygwin or SFU is a nonsense.
urxvt or xterm if you want to run X, mintty or puttycyg if you don't.
Cygwin 1.7 does support case-sensitive filenames. See the User's Guide on how to enable it: http://www.cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive It's also had various other improvements in terms of POSIX compatibility, for example, characters not allowed in Windows filenames can now be used in Cygwin. Another one is that mount points are now stored in /etc/fstab rather than the registry. See the What's New section for lots more improvements: http://cygwin.com/cygwin-ug-net/ov-new1.7.html
The Cygwin developers do have an official Linux compatibility goal, and fixes are going in all the time, but of course it's never going to be perfect, partly due to limitations of the underlying platform, and partly due to lack of (wo)manpower.
Good points about avoiding fork where possible. spawn() is another way to do that.
How exactly can andLinux be described as less convoluted than either Cygwin or SFU? Instead of just the C/POSIX libraries, you also get most of a Linux kernel sitting on top of the Windows kernel.
- The latest version is available for all Windows (>=NT) variants, not just Enterprise and Ultimate.
- It's more compatible with GNU/Linux extensions (since SFU is not aimed at that).
- It's open source with open development, short release cycle, and responsive mailing list.
- Package system. (It's no apt-get, but it does its job, including dependency resolution and updates.)
- Bigger, more recent choice of packages. For example gcc, is 4.3 vs. SFU's 3.3.
- Bash and zsh.
- A usable default shell configuration. The arrow keys don't even work correctly in SFU's default ksh setup. (It's as if MS deliberately try to scare people off Unix.)
- A choice of terminals to replace the awful Windows console.
Also, what do you base your claim of SFU's better Windows integration on? Since Cygwin's based on the Windows API rather than being confined to its own subsystem, it can offer features like /dev/clipboard or /proc/registry, and it allows programs to mix POSIX and Win32 calls.
Finally, Cygwin 1.7 does also support case sensitivity on NFS and on NTFS volumes that have that feature enabled.
Yep, a scheme for keeping processes using different Cygwin DLLs out of each other's way has been implemented. Just don't expect them to interact with each other, e.g. you can't send signals from one Cygwin sandbox to another. That's why the best approach still is to have only one Cygwin DLL on your system.
Cygwin can't use the NT fork support, because it's implemented on top of Win32, and NT's fork does not support Win32 DLLs. Obviously that is a significant disadvantage, particularly during fork-heavy 'configure' runs, but there are also advantages that approach too, e.g. it allows things like /dev/clipboard for accessing the clipboard and /proc/registry for accessing the registry. It also means that Cygwin programs can mix POSIX and Win32 calls, so when porting from Unix to Windows you can take a gradual approach, or just port the UI only.
MinGW does not have a bash shell, because it provides nowhere near the level of Unix compatibility required for bash (as that's not the aim of the project). There is an MSYS version of bash, but MSYS in fact is a (more or less unmaintained) fork of Cygwin 1.3.
Good post. Regarding the last point about the default console, Cygwin ships with a number of replacement terminals: (u)rxvt, xterm, mintty. Mintty in particular provides a native Windows interface with Unicode support and does not require an X server. More at http://mintty.googlecode.com/
I think the Unicode and internationalization support is the most important improvement in 1.7, making it much more useful for people who need more than ASCII. There's been a lot of under-the-hood work to convert the Cygwin internals from using Windows "ANSI" APIs to Unicode APIs. Cygwin's filesystem will automatically translate between Windows filenames, which are encoded as UTF-16, and POSIX filenames, which are encoded as UTF-8 or whatever other charset you might have selected.
Mintty. Available from http://mintty.googlecode.com/ or under 'Shells' in Cygwin's setup.exe.