
Gow – The lightweight alternative to Cygwin - urza
https://github.com/bmatzelle/gow/wiki
======
markokocic
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.

~~~
vog
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.

~~~
wyz
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.

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

------
malkia
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"

~~~
ComputerGuru
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-...](http://neosmart.net/blog/2011/open-source-100-compatible-ln-for-
windows-and-junction-point-library/)

disclosure: my site

~~~
malkia
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).

------
4ad
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>

~~~
RexRollman
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.)

~~~
4ad
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/>

~~~
soapdog
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.

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

~~~
DiabloD3
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.

~~~
wyz
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.

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

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

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

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

~~~
swah
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.

------
xpaulbettsx
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.

~~~
tikhonj
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.

~~~
natesm
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.

~~~
nupark2
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.

~~~
chalst
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.

~~~
saurik
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.

~~~
chalst
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.

~~~
saurik
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.)

~~~
chalst
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.

~~~
nupark2
_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.

------
daemin
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.

------
snotrockets
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.

------
zoobert
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

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

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

~~~
ComputerGuru
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.

~~~
barrkel
Cygwin sshd is not statically linked.

~~~
ComputerGuru
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.

------
niyazpk
No support for Pipes. :(

------
bbulkow
The real point:

1) if you want to program in "gnu", run _u_ nx, 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.

------
mhartl
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_.

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

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

~~~
elmindreda
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.

~~~
fragsworth
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.

~~~
elmindreda
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.

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

------
keshet
No awk? I'm outta here.

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

------
tommica
I DEMAND SUBVERSION!

------
earl
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...

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

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

~~~
haridsv
There is someone paying to do this port right now:
[https://www.odesk.com/jobs/Port-linux-
bit_~~2416926dd8d9a963...](https://www.odesk.com/jobs/Port-linux-
bit_~~2416926dd8d9a963?_redirected)

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.

