Gow – The lightweight alternative to Cygwin | Hacker News Reader

Gow – The lightweight alternative to Cygwin

github.com

181 pointsurza93 comments

I understand why someone wouldn't like to use cygwin, but why new project?

MSYS/mingw-get are active projects that provide a good base to build upon. Why not helping improve it? Unix tools on Windows is niche enough so that choice only leads to fragmentation, not competition.

This is exactly what I also thought when I read the headline. And this becomes even more strange given that they are almost certainly building upon using MinGW.

I have used MinGW, and MinGW is terribly slow comparing to Gow. Do a simple "ls" you will feel the difference. Not to mention bash.

In your statement, you are confusing MinGW with MSYS. But I see your point.

Cygwin is not perfect, but he's the thing that I prefer over other options.

It's unix emulator layer, and as such tries it's best to emulate fork() - which the other alternatives does not even think to put in.

VM is not a real alternative, as there is actually more work to be done to plumb source A with tools B from the VM.

I don't use cygwin from bash, but rather start it directly from the FAR manager (console based Norton Commander/Midnight Commander application for Windows). It's very useful, as a lot of commands just work.

Then there are others, which are some kind of symlink (one of the downsides of cygwin for me), but that's understandable. Symlinks as they are on linux are just starting to appear on Windows Vista and 7 (and I'm not even sure how compatible they are).

So for such cases, sh -c would work. For example checking out latest SDL using cygwin, but from the command-prompt:

c:\p\sdl> sh -c "hg pull -u"

And then other stuff works even better:

c:\p\libzmq> git pull -u c:\p\libzmq> sh -c "gitk --all"

Regarding symlinks on Windows:

http://neosmart.net/blog/2006/vista-symlinks-revisited/

And an open source (MIT) binary-compatible implementation of ln for Windows Vista+ using native WIN32 APIs:

http://neosmart.net/blog/2011/open-source-100-compatible-ln-...

disclosure: my site

Thanks a lot! SysInternals, NirSoft tools and anything that I can find for Windows is very very much appreciated. (At home I'm sticking to OSX and Ubuntu, but at work the situation is rather different - I'm often finding myself arguing with myself - at home I prefer gnome/gtk, at work I better stick to Windows.Forms, hehehe).

I find it strange that no one is mentioning UWIN[1], started by David Korn about the same time and with the same goals as Cygwin.

I used to use it. I liked the fact that it used the host compiler instead of gcc, plus I preferred the non-GNU tools.

Now I'm using Inferno, it works much better. It's not Unix, it's Plan9, but I view that as a plus. Of course cygwin can install all kinds of Unixy tools, like gcc, openssh, xterm and whatnot. Inferno doesn't come with anything, but I don't need anything except the basic Plan9 tools.

[1] http://www2.research.att.com/~gsf/download/uwin/uwin.html

You run Inferno on top on Windows as an application? I have read that this is possible but I have never seen anyone doing this, not even in a screenshot. If so, what's your opinion of it as an environment?

(By the way, Inferno's implementation reminds me of Niklaus Wirth's Oberon, which could also run as either an application or as an operating system.)

Yes! Inferno can run both native, on the bare hardware, or hosted under Unix, Windows or Plan9. Most people run Inferno hosted because it's easy and you can benefit from the host operating system services as well.

For me, it's the best environment because I can have Acme (the editor), Plan9 name spaces and the Plan9 tools which I am most familiar with on any operating system I use. You can use either full Inferno [1] or Acme SAC [2]. Hosted Inferno runs in a window, which feels awkward to me, so I use Acme SAC which is a native host window and I run the shell inside Acme. Acme is the only graphical Inferno program I care about anyway.

[1] http://www.vitanuova.com/inferno/downloads.html

[2] http://www.caerwyn.com/acme/

Thanks for the links. Can you elaborate more on what you like about Acme? I am not bashing it, I just want to know, never used Acme.

How does this compare to the MinGW/MSYS (http://mingw.org) project?

I was about to ask the same question. MinGW is already the lightweight alternative to Cygwin, and has largely taken over for the task of compiling unixy things on Windows.

The major difference between MinGW and Cygwin is MinGW tries to use native Microsoft libs by dummy wrapping them (like, MS's libc is often compatible with POSIX standard stuff, the POSIX version merely starts with _ frequently, MinGW uses this fact).

Most stuff that won't compile "natively" on Windows through Visual C's compiler, those projects use MinGW, I never hear of anyone using Cygwin especially because of the requirement of shipping the Cygwin runtime dll (of which MinGW has none).

Even Strawberry Perl, the Perl distro for Windows, uses MinGW to compile XS perl modules from CPAN.

The biggest difference to me is: Gow is amazingly FAST!

I have used MinGW and it is extremly slow, I need to always remind myself to use dir instead of ls, otherwise it's a few seconds' wait.

However, I do not think Gow is able to compile. (I did not really look into the documentation as github is blocked in my office.)

Another difference is MinGW appears to provide more up-to-date binary. e.g. bash in MinGW is 3.1 and in Gow is 2.03. And vim in Gow is 6.3 only.

Sorry, but... GitHub is blocked in your office!?!

Oh, heretics! How dare they leave ed out of the list [1]?

[1] https://github.com/bmatzelle/gow/wiki/executables_list

ED IS THE STANDARD UNIX EDITOR! IT MAKES THE SUN SHINE AND THE SKY BLUE AND THE GRASS GREEN!

I DON'T NEED TO SEE THE STATE OF THE FILE! I KNOW THE STATE OF THE FILE! I JUST NEED YOU TO CHANGE THE FILE.

  william@aldebaran ~ $ ed
  bash: ed: command not found

Here is the joke: http://www.gnu.org/fun/jokes/ed.msg.html

I recently decided to learn ed, as I felt it couldn't hurt to be familiar with it, and I was surprised to see that it wasn't installed in Arch Linux by default.

If one has bash as the default shell, why not ex as the standard line-oriented text editor?

Postscript - ex is the version of ed rolled up in vim, which extends the command set of ed. vi, by contrast, handles colon commands by invoking ed externally.

IIRC, I became interested in ed after reading about the Plan 9 editor Sam, which was described as "ed on steroids, lots of steroids"[1]. Sadly, I never got around to trying Sam.

[1]http://sam.cat-v.org/

"ex is the version of ed rolled up in vim, which extends the command set of ed. vi, by contrast, handles colon commands by invoking ed externally."

Actually vi and ex came about at the same time. You can see the POSIX standard mentions [1] ex and vi (not vim) together, and you can also refer to [2], under the "First appeared" column.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex...

[2] http://en.wikipedia.org/wiki/List_of_Unix_utilities

Indeed, there is a mistake in what I wrote. What I should have said is that Bill Joy wrote ex, and then he used this implementation to write vi. Vim is like vi in that it comes with an ex built in, which is an extension of Bill Joy's ex.

We really need to port Homebrew to Windows so that projects like this can be the base, but people can pull in packages on top of it, like a lightweight Cygwin but more Windows'y.

Does porting Homebrew make any more sense than porting something from Linux (for example)? My impression is that the Mac OS ones aren't as good.

A package manager really sounds like the sort of project where the incompatibilities between *nix and Windows are large enough that writing a new one would make more sense. I think there are even existing projects like that for Windows; I remember seeing one on HN a while back, but can't recall the name.

The advantage of Homebrew is that it is modern, small, and simple. Obviously apt is better, but apt also requires that you maintain a large repository of binaries. Homebrew is slow[1], but because it builds from source it is trivial to create a new package. Homebrew packages are just Ruby files. If the project uses Autotools, all you generally need to do is enter the URL, an md5, and the dependencies, then it Just Works. If it uses waf or something it's still just a simple modification.

Instead of reinventing its own selfupdate functionality, Homebrew just uses git. Updating Homebrew is really just fast forwarding a git repository. Finally, the maintainers explicitly do not duplicate the libraries/tools that ship with OS X.

This is a big step up on OS X from Macports, which installs itself in /opt/local and rebuilds everything possible. Homebrew is instantly understandable. Packages are files, you just match them by name. apt is admittedly more complex, but at least you get something for that complexity.

[1] really what's slow is building from source. Homebrew itself is very fast.

Everything you just said (packages are files, simple, uses existing tools for self update) applies to MacPorts too. The only real differences seem to be the use of Ruby, and an attempt to avoid replacing OS dependencies -- even if the replacements are newer.

In fact, MacPorts actually supports generating Debian packages and an apt repository straight from its port files.

As for Windows, Cygwin already provides binaries. An apt repository of them would be great. I'm not convinced porting homebrew or MacPorts makes sense, however -- they're both fairly Mac-focused.

Macports builds something of a sandbox, which from the users point of view is neither small nor simple.

It is easier for the Macports team to make sense of bug reports with a sandbox, however, which is, I assume, why they do it. It is explicitly the reason they forbid installing to /usr/local.

Macports used to not build this "sandbox", but learned the lesson that relying on Apple as your only source of updates to critical base libraries was fraught with peril: not only do you not get updates you might need ("upgrade to 10.6" is not a reasonable response to someone who just wants to use a project that needs a slightly newer version of libcurl), but sometimes Apple can ship changes that break compatibility without realizing it (as they were not using that part of the library). Once you start dealing with this complexity, the sandbox is actually much /simpler/, as you get well defined results: the only variability are changes in kernel behavior, which tend to be a much less shifty target.

The "sandbox" increases the complexity of the system that the user deals with. The other notion of simplicity is one that should matter only to the Macports developers.

I do not like to criticise open-source projects, but the (reasonably polite) hostility that stating this simple fact has attracted does make me think that the supporters of Macports have stopped seeing things from the user's point of view.

If you want a packaging system whose job is to protect you from the risk of certain rare but possibly messy mishaps, then Macports might well be what you want. I recommend being less risk averse, and use a mixture of Homebrew and installing to /usr/local. It will cost some research and reinstall time now and then, but it will result in a system that is easier to get an overview on.

The talk I have seen of "destroying" one's system installing via Homebrew is pure FUD, and I do not know what lies behind it.

As a user, I find knowing that "install X from MacPorts" should always work, no matter what underlying version of Mac OS X I have, can always be up to date with the latest features, without having to update Mac OS X, and won't fail when I /do/ want to upgrade Mac OS X, the definition of "simplicity".

(Honestly: what does Homebrew make simpler than MacPorts anyway? Near as I can tell, the only reason people seem to like it is that it doesn't take as long to compile software, which argues more strongly to me that we need binary distributions that can download pre-compiled copies than that we should attempt to use the libraries to save installation time.)

Why I prefer Homebrew:

1. No alternative copies of Python, Perl, Ruby, zlib, etc...

2. Everything installs to where it is supposed to, i.e., under /usr/local/

After installing via Homebrew, things do not look drastically different to having compiled them by hand.

Fink does install precompiled binaries: http://www.finkproject.org/

If you think there is no complexity issue with sandboxes, try using both Macports and Fink side-by-side.

1. No alternative copies of Python, Perl, Ruby, zlib, etc...

And if I need a newer version of Python, coupled with a dependency tree of third-party modules?

I don't see why this matters, other than some pedantic sense of cleanliness ("NO DUPLICATES!" ... even though they're not, in reality, duplicates).

2. Everything installs to where it is supposed to, i.e., under /usr/local/

You can configure MacPorts to do this, but the reason it's not the default was to leave /usr/local for the user's own manually installed software. I don't think this really matters either way.

After installing via Homebrew, things do not look drastically different to having compiled them by hand.

I don't know what this means or why it matters.

Are you perhaps thinking about the CoApp project? It's making some decent progess, check out CoApp.org for updates. Last I heard they were in the process of shallow-forking a slew of OSS projects and building them natively in Windows.

pkgsrc already supports Windows Services for Unix, it may well work on top of this too (though I haven't looked at Gow yet and I honestly have no idea how it differs from MSYS).

But when I think "Unix-like core plus package management on Windows"... well, Cygwin is already there.

SFU/SUA only work on enterprise/ultimate versions of Windows. Also, pkgsrc is reported to work, but who actually tries it know it works pretty bad and it requires lots of manual patching.

https://code.google.com/p/apt-cyg/

"apt-cyg is a command-line installer for Cygwin which cooperates with Cygwin Setup and uses the same repository. The syntax is similar to apt-get. Usage examples:"

    "apt-cyg install <package names>" to install packages
    "apt-cyg remove <package names>" to remove packages
    "apt-cyg update" to update setup.ini
    "apt-cyg show" to show installed packages
    "apt-cyg find <pattern(s)>" to find packages matching patterns
    "apt-cyg describe <pattern(s)>" to describe packages matching patterns
    "apt-cyg packageof <commands or files>" to locate parent packages

Well for a far more light weight solution there's GnuWin32 and GetGnuWin32 (which installs GnuWin32), both available via an easy Internet search. They both run from the command prompt and you don't need any other environment for them.

This is not an alternative to Cygwin, and shouldn't be called such.

Cygwin isn't a collection of binaries; that's a distribution. But the idea is to emulate UNIX, including fork(), etc., allowing you to easily recompile for Windows.

Would be good to have a standard ssh client similar to the ones in linux and other unixes. I use Cygwin mainly for that. I do not want to do putty -ssh ... and I want to copy my keys and other config in ~/.ssh. Like that I can "standardize" the way I setup my accounts on cygwin and linux. Without that it is kind of a big hassle

Is there an SSH server for Windows that will work with this?

Or an SSH client which can be called by the gow shell?

In reply to both yourself and guan, the answer is openssh: http://sshwindows.sourceforge.net/

While it is built with cygwin, I believe it's statically linked to get rid of the dependency hell. You don't have to take into consideration that it is a cygwin binary.

Cygwin sshd is not statically linked.

I can no longer edit my answer, but I just downloaded it and extracted the setup archive - you're right. OpenSSH for Windows is not statically linked to cygwin.

I do, however, still think it's possible to statically link OpenSSH with Cygwin, in which case it would become the answer to the original question.

KpyM seems to do a decent job of providing SSH access to a cmd.exe prompt (and anything you care to run from one). It's free although the provided binaries do an annoying nagware thing on login. I've been using it for SCP access to Windows servers.

http://www.kpym.com/2/kpym/index.htm

Semi-related: PowerShell Server, a commercial Windows SSH server with a free restricted license (notably a single connection and only password authentication):

http://www.powershellinside.com/powershell/ssh/

No support for Pipes. :(

The real point:

1) if you want to program in "gnu", run unx, and if you want Windows as your host OS, run virtualization; (yes, you need 8G, yes, you should have an SSD, if you don't, buy a new laptop for $700 and run linux native)

2) if you want a better command line, There's lighter weight ways like http://unxutils.sourceforge.net/ http://gnuwin32.sourceforge.net/packages/coreutils.htm ... and a set of binaries I found 5 years ago that seem to have vanished, works OK for me.

Has anyone used this to run Ruby on Rails? If so, I might want to recommend it in the next edition of the Rails Tutorial.

A smtp client (e.g. something like msmtp or ssmtp) so scripts can send email easily would be a nice addition.

What is the use case for Cygwin in the days of virtualbox/vmware?

Running Unison for easy local mirroring/backup, if nothing else.

Because not everyone want to emulate an entire PC just to run a Unix command?

Git

That's available on Windows natively.

Really? I wasn't aware... since when?

http://code.google.com/p/msysgit/

MSYS is just as native as Cygwin

Not true. MSYS is mainly wrappers around existing, native WIN32/MSVCRT function calls.

Prior to Fall 2007 when I started using Git on windows.

I like Windows 7, but I prefer bash for my console. Enter Cygwin + Console 2. Now life is better.

Being able to use a real shell with all the tools I'm used to when developing on Windows.

Cygwin in combination with MinGW and the Windows native version of GVim lets me have almost exactly the same environment as I do on Linux and Mac OS X.

You could mount the Windows filesystem from the Linux VM, and use the shell tools that way.

I agree, though, it's still better to have Cygwin, because you can alt-tab and such.

I don't see Cygwin as a file manager but as another (better) interface to Windows. A Linux VM wouldn't let me natively run and debug Windows software, which is the entire point of me being in Windows in the first place.

Cygwin gives you (seamless) access to the Windows file system. Is it possible to (say) 'sed ... | wc' a file in the host's directories from a VM?

yes. for example in virtual box you can mount host's directory tree within the vm either in rw/ro mode. from then on, things are seamless.

I thought Windows' default filesystem (NFS?) was not safely writeable from Linux. Does your method involve changing Windows' filesystem?

Windows default filesystem is NTFS and it's pretty safe to write. I certainly wouldn't set up something like a server which relies on this, but for personal use or even a development workstation I think it's fine.

I guess it might be a good idea to first check the disk using Windows after something like a power loss while the NTFS partition is mounted. But apparently NTFS-3G (one of the NTFS drivers) can also use the journal to recover the filesystem after a power loss.

For certain definitions of seamless. Windows has a habit of messing up nix file permissions and sometimes things just don't work at all unless you do it on the Windows side.

Or even andLinux [1], which gives you "a complete Ubuntu Linux system running seamlessly in Windows".

[1]: http://www.andlinux.org/

*32-bit only

Half-decent interop between the unix-y bits and the Win32 native bits.

e.g., you might want to have a mostly unix-style build process that uses VC++ as the C compiler, and run it all inside Visual Studio using a makefile project.

I work at a company that currently provides a 32bit version of Windows 7 (the reasons are somewhat unclear.) But the bottom line is that we have the 3gb max addressable memory problem. When I have eclipse, outlook, chrome, various other dev tools and whatnot open, I'm often near the limit, and adding VMWare player or whatnot would probably be too much. So that's one reason... Plus, I find switching back and forth between a vm and the host OS still somewhat slow/clumsy.

(Yes, I know I should get a new job...)

I like the idea of Gow. Anyone know if you can achieve middle mouse button pasting as when you have X11 under cygwin?

Most folks use Putty to avoid the strange switching. Then its like a better command window.

I'm a UNIX and Mac OS X transplant using Windows for embedded hardware development (almost all the tools are Windows-only).

I need a terminal from which I can operate on my Windows file system, but running an entire virtual machine is enormous performance-impacting overkill.

I work with a hosting provider and Cygwin is used all the time to provide SFTP access on Windows boxes. Haven't looked at sshwindows though.

WinSCP works very well for sFTP. http://winscp.net/eng/index.php

Using Unix utilities (including Unix paths and forking semantics) on your Windows system. I regularly use Unix utilities to e.g. manage Windows processes; frequently, when a game crashes and leaves me with a blank screen, I can blindly alt-tab to a terminal and 'killall foogame', or if it's worse, ssh in.

I use Cygwin to get approximately the same terminal environment in Windows as I do in Solaris, Linux and Mac. I have a suite of scripts to massage platform differences (e.g. Cygwin getclip / putclip vs xclip vs pbcopy / pbpaste, or cygstart vs open vs gnome-open / xdg-open / etc.). It means that in the terminal environment, I'm equally at home no matter what the OS.

I run Cygwin in rxvt. Using a better terminal than a Windows command window is a must; until I started using rxvt, I didn't even live in bash. Rxvt / bash combo uses considerably less memory, less startup time and less disk space - my dual-boot macbook air has Cygwin installed in the Windows 7 partition.

another interesting older project along the same lines is gnuwin32 [http://gnuwin32.sourceforge.net/]

No awk? I'm outta here.

Well Brian Kernighan offers a Windows download, though I use awk.exe from Inferno.

It has gawk

I DEMAND SUBVERSION!

A somewhat heavier version of cygwin, in which everything will work the way it's supposed to: http://www.centos.org

I kid, I kid...

Then there's always colinux - where you can have both, at the same time, without virtualization.

I was surprised that colinux wasn't more popular than it is. I remember thinking it was a pretty good idea when it was announced.

It has been on and off in its quality.

Colinux doesn't run in 64 bit Windows, unfortunately.

There is someone paying to do this port right now: https://www.odesk.com/jobs/Port-linux-bit_~~2416926dd8d9a963...

In my last job, I used colinux with Windows 7 and it was a match made in heaven. But when I moved, I had to choose the next best thing, which is Mac OS X, because of lack of support for 64-bit windows.

But then you can't run a decent Window Manager like Windows 7.

Reply on news.ycombinator.com