
Gow – The lightweight alternative to Cygwin - pmoriarty
https://github.com/bmatzelle/gow/wiki
======
quotemstr
Cygwin is a fantastic system put together by people crazy and talented enough
to dig deeply into both the POSIX world and the NT world. I can't recommend it
highly enough. A bag of ported _utilities_ is absolutely no substitute for
something that, in effect, amounts to GNU/NT.

Yes, there are some warts, but they're papered over remarkably well. Give
mintty a shot: you'll never go back to conhost.

~~~
gregschlom
> Give mintty a shot: you'll never go back to conhost.

No, give cmder a shot:
[http://bliker.github.io/cmder/](http://bliker.github.io/cmder/) I've tried
mintty and cmder, and cmder was just perfect for me.

~~~
ElliotH
Oh my goodness thank-you! I'm forced to use Windows at work, and this is the
first terminal emulator that looks not terrible!

~~~
kyzyl
Might take a look at Babun[1] as well. It's a fairly pretty emulator with a
built-in cygwin tree, and integrated (default) zsh.

[1] [https://github.com/babun/babun](https://github.com/babun/babun)

~~~
whoopdedo
The problem I have with console replacements is most of them break readline.
You can't run many interactive programs with them. On the other hand, you
can't have full unicode support without a console replacement.

~~~
quotemstr
Indeed. People need to stop thinking in terms of building win32 "terminal
emulators" (most of which involve god-awful hacks, like scraping hidden
conhost windows) and instead emulate the Win32 console API in userspace (just
like Windows itself did before Windows 7) and implement the Cygwin pty
interface in terms of this library. This way, Cygwin programs think they have
a pty and Win32 programs think they have a console, and everything Just Works.

But people would rather just hack up a "terminal emulator" instead of doing
things the properly and the hard way.

------
xfGnB6P
I gave Gow a shot when I got a new Windows PC at work a while back. In my
experience it is completely broken for anything but the most trivial use
cases.

Basic things didn't work, like "ls -t|head" (broken/missing SIGPIPE
implementation IIRC), and "(g)find -iname '*.txt'" (I could not for the life
of me stop it from expanding the glob).

I gave up after a couple days and went back to cygwin.

~~~
mlvljr
Was my experience with Cygwion itself 9 years ago or so -- broken beyond
usable for anything except look-ma tests :)

------
deng
From the looks of it this is definitely not an alternative to Cygwin, because
the latter implements a complete POSIX layer. Instead, this seems to be a
collection of native and MSYS binaries, which is fine and all, but I kinda
doubt that they have the quality of ezwinports, which is still the best
address for native Windows binaries of free software. Also, they don't provide
the source and the build scripts for their binaries.

~~~
GilbertErik
Yeah yeah. I opened this:
[https://github.com/bmatzelle/gow/issues/164](https://github.com/bmatzelle/gow/issues/164)

Please comment with clarifications.

------
Sir_Cmpwn
This doesn't really seem like an alternative to Cygwin. Cygwin is valuable
because it provies a POSIX environment. I write my programs for sane systems
and then Cygwin allows me to get them running on Windows fairly easily.

------
jackalope
When I used to install Cygwin, it was to get (in order of importance): ssh,
vim, rsync & X11. Gow doesn't include the last two, so it feels like an
apples/oranges comparison (for my use case). Still, it's pretty amazing what
Windows doesn't include by default in this day and age, so a simple,
lightweight set of tools like this definitely has its place.

I don't use Windows anymore, but if I did, I would probably just spin up a VM
with a tiny live Linux ISO, because it would bring in so much other goodness
without any extra effort.

~~~
vertex-four
> Still, it's pretty amazing what Windows doesn't include by default in this
> day and age

It includes the majority of stuff you'd want as part of Powershell, just under
different names, and not available as separate executables on the filesystem.
If Powershell is lacking something, you can access any .Net class on the
system. Once OneGet is released with the next version of Windows and people
start packaging stuff for it, you'll be able to grab additional utilities for
pretty much anything.

Windows isn't _that_ far behind. It's mostly just not UNIX. Most things are
there, just done in very different ways.

~~~
oblio
Equivalents for:

wget or curl

lftp

dig

telnet

And I mean similar features, not Invoke-WebRequest, ftp, nslookup or writing
my own clone in 2000 lines of Powershell.

And to this day I have no idea why telnet was removed from the base
installation.

The Windows command line is getting better with Powershell, but even
Powershell can't beat 1000 man years of tool development. And I really hope
that package manager takes off cause right now most Windows non-Microsoft
tools are either shady or crappy.

~~~
halo
I'm only speculating, but I imagine telnet was removed because the security
issues and misuse vastly outweighed the legitimate use by powerusers.

And I'm not really sold that an OS should ship with a bloated utility like
modern wget rather than including a very lightweight downloader.

On the other hand, I think PowerShell is a vastly over-complicated and over-
engineered response to the conceptually simple Unix shell, which is why most
still favour the command line.

~~~
oblio
telnetd ok, but telnet itself? What for? Crappy, slow, port scanning?

~~~
lukeschlather
Removing telnet nudges people to completely stop using telnetd. I know there's
a ton of embedded devices that require telnet, but these devices are
increasingly going to become a liability and Microsoft probably made a good
decision here.

~~~
xorcist
That doesn't make sense. If I need to configure a switch, test an http server,
or whatever it is I need telnet for, I'm going to download PuTTY. No (sane)
person ever went "screw that, telnet is insecure, I refuse to do it".

------
geofft
I like how we live in a world where you can say "open source" and put a bunch
of compiled binaries in a bin directory. Leaving aside the trail of GPL
violations, it's ... certainly something ... that the phrase "open source"
doesn't make people think about whether source should be _present_, open or
otherwise.

The "contributing" page is pretty awesome, along the same lines: it describes
a list of things you need to do in order to ask the maintainer to implement
the feature you want.

------
justincormack
The repo does not seem to have the source code, which is a bit of a problem as
most of the software is GPL.

------
UnoriginalGuy
> Shell window from any directory: Adds a Windows Explorer shell window
> (screenshot) so that you can right-click on any directory and open a command
> (cmd.exe) window from that directory.

Windows already has that, hold down shift and right click either on a
subfolder or in the white space/nothing within an open folder.

Since, I dunno, XP maybe? I don't think 2000 had it. I know Vista did.

~~~
gentlebend
While we're on the topic, here's a cute tip: To make the opposite move -- from
the command prompt to an explorer window of the current directory -- use
"start ."

~~~
girvo
Similar, for OS X use "open ." (or replace the "." with whatever file you want
to open)

------
callesgg
Unfortianly Gow is very buggy.

And the maintaner does not reveal sources for the binaries, which makes it
hard to help out. In practise he is acctualy breaking the GPL license, by not
giving sources.

------
lnanek2
This doesn't seem to have some of the things I use in Cygwin, so it useless to
me. Also 10MB vs. 100MB is irrelevant to me. I don't download any movies and
music or anything like that so my tiny flash hard drives still have plenty of
room to make that difference irrelevant. Might be good for some people.

------
bsenftner
Looking at the change_log, it does not look like their version of BASH has
been updated recently, indicating it is capable of the ShellShock exploit.

~~~
Elrac
This seems hugely irrelevant to me. Would you consider using Unix lookalike
utilities under Windows to launch an Internet-facing Web server that allows
users to do CGI scripts? Because that's pretty much the only scenario where
ShellShock would be an issue.

------
vram22
I had used UWIN for a while a few years ago, when I was on Windows and needed
UNIX functionality:

[http://en.wikipedia.org/wiki/UWIN](http://en.wikipedia.org/wiki/UWIN)

It was originally written by David Korn, creator of the Korn shell. Can't
forget "ksh -o vi", which let you edit your command history with vi commands.
(It is like "set -o vi" on bash these days.) I used to use it as the last line
in my .kshrc.

[http://en.wikipedia.org/wiki/David_Korn_(computer_scientist)](http://en.wikipedia.org/wiki/David_Korn_\(computer_scientist\))

Not sure where UWIN stands in comparison to Gow and Cygwin but it was somewhat
useful. IIRC, it was at least more than a collection of UNIX utilities.

The installation procedure (from an AT&T site) was a bit of a pain but doable.

------
jhallenworld
They should provide tools that run in both Windows and plain MS-DOS / FreeDOS
(hey, sometimes it's useful). One way I know how to do this is to compile with
[http://www.delorie.com/djgpp/](http://www.delorie.com/djgpp/) and link in the
CWSDPMI DOS extender from
[http://homer.rice.edu/~sandmann/cwsdpmi/index.html](http://homer.rice.edu/~sandmann/cwsdpmi/index.html)

The DOS extender will not run if it detects DPMI provided by Windows, so the
binaries work in both environments.

I suggest this for some Atari 800 utilities I wrote:
[https://github.com/jhallen/atari-tools](https://github.com/jhallen/atari-
tools)

------
jedisct1
What's the point over MSYS2?

------
lolive
I dunno about Gow. But I have been very happy with the (not so) small package
included in MobaXterm: ssh, X11, busybox, git, perl, ...
[http://mobaxterm.mobatek.net/](http://mobaxterm.mobatek.net/)

------
natch
>"Gow is one of the few things that makes Windows bearable/usable"

Good quote, but that is not necessarily a positive if you look at things from
the perspective of the sooner Windows is ditched, the better.

~~~
quotemstr
Why? Windows is an excellent system and gets a lot of things right that POSIX
gets wrong. WMI is wonderful; COM is wonderful; the NT kernel is from 1989 and
still worlds ahead of Unixy kernels in many respects. (It's 2014 and I still
can't open a file descriptor that represents a process.)

~~~
orf
I think some of your examples are iffy, COM and WMI are sometimes wonderful
but sometimes definitely not. Windows is not perfect and POSIX is better for
some use-cases, vice versa.

~~~
quotemstr
Of course. The systems have a lot to learn from each other, to be honest. One
of my biggest gripes back when I worked on the Windows team was the lack of a
pseudoconsole API equivalent to the Unix pty interface.

That said, using Cygwin is, as far as I'm concerned, the best of both worlds.
Unlike some people, I like integrating the two environments as much as
possible. I install Cygwin to C:\, for example, and I added support for using
native win32 widgets to Cygwin Emacs. (Try the cyg32 package. You'll like it.)

Try the "injob" utility too. It gives you native Unix job control with
arbitrary Windows programs. (That it's even possible to implement it is a
consequence of NT job objects being much better abstractions than POSIX
process groups.)

------
nstart
I use cygwin on a daily basis and the only question I have is, apart from a
smaller disk space footprint, which is becoming increasingly relevant, how
much more lightweight does one need cygwin to be? This obviously does not
apply to the true power users of cygwin. I was thinking more along the lines
of a general user of it. Basic greps, batch file operations, etc.

------
johnloeber
Honestly, I don't really understand why people use UNIX-shells like Cygwin in
Windows. I found them slow and difficult to work with, to the extent that it's
much easier to just spin up a VM with a lightweight Linux distribution (or to
dual boot, but that's another use case).

~~~
roxtar
I develop on Windows for Windows and use these tools. Here is my reasoning.

It's easy to see that Unix shell tools are much superior to the Windows cmd.
There is PowerShell which gives you more flexibility, but in my experience I
have found PowerShell to be slow. It also has a totally different set of
syntactic rules which aren't worth my time to learn.

Given that, I would rather install Cygwin or MinGW. Spinning up a VM is much
more heavy-weight that just directly using Cygwin.

~~~
UnoriginalGuy
> There is PowerShell which gives you more flexibility, but in my experience I
> have found PowerShell to be slow.

Powershell can be a little slow to launch. Actual execution speed is pretty
respectable. It does get faster after the first couple of times as it will
ngen stuff into the GAC (this is particularly bad on new Windows installs
where little .Net code has previously ran in any contexts).

It can be fixed by running a script like this:

[http://blogs.msdn.com/b/powershell/archive/2008/09/02/speedi...](http://blogs.msdn.com/b/powershell/archive/2008/09/02/speeding-
up-powershell-startup-updating-update-gac-ps1.aspx)

Which will populate the GAC.

> It also has a totally different set of syntactic rules which aren't worth my
> time to learn.

You're missing out. Powershell's syntax is quite intuitive after you learn the
basics, you quickly start to be able to guess commands and params.

~~~
roxtar
>> It also has a totally different set of syntactic rules which aren't worth
my time to learn.

>You're missing out. Powershell's syntax is quite intuitive after you learn
the basics, you quickly start to be able to guess commands and params.

I have grown up using Unix tools and I am quite comfortable with them. If I
have to learn a new shell and scripting language, there should be a
demonstrable benefit for the time I spend learning it. Can you give examples
where PowerShell can do something which CygWin/MinGw can't? Trying to
understand why you say that I am missing out :)

~~~
staticshock
The main benefit of PowerShell over other shells is the object pipeline.

In classical shells, a pipe basically connects binary stdout -> binary stdin.
A pipe between PowerShell cmdlets, on the other hand, can produce .NET objects
directly without having to serialize them, so the pipe can connect .NET object
producer -> .NET object consumer. If the consumer can't handle objects, the
pipe degrades to binary stdout -> binary stdin.

For instance, the pipe in `ls | grep` is drastically different from `ls | fl`,
because the latter is an in-process transfer of a .NET object collection,
while the former transfers lines of text from one process to another, (in this
case, to GNU Grep.)

Upside: the consumer doesn't have to "parse" stdin to get reasonable data on
which it can operate.

Downside: if you want to write a consumer, you're stuck in .NET land. (Oh, how
I wish I could write a consumer written in python that could advertise that it
supports a specific object-oriented serialization on stdin! Then we could
write a PowerShell stdin/stdout compatibility layer into python as a module...
Alas, I'm guessing this task is reasonably hard.)

Oddly, I couldn't find a great readable intro to the topic, but this comes
close: [http://www.darkoperator.com/blog/2013/1/28/powershell-
basics...](http://www.darkoperator.com/blog/2013/1/28/powershell-
basicsndashobjects-and-the-pipeline.html)

~~~
netheril96
The main problem of object pipeline is that only software written .Net
understands it. That means most of the utilities we are familiar with in the
Linux world doesn't work with them.

And I don't want to find every .Net equivalent of the command I use in Unix
systems. Perhaps all the coreutils have counterparts in Powershell, but for
all the other third party ones I use, probably not.

------
baq
i already have msysgit and mingw. should i use gow?

~~~
rossy
Probably not. From the looks of it, GoW is just a mashup of MSYS and MinGW
compiled binaries, much like msysGit except without Git.

------
kolev
I've been using Babun [1] and fully enjoying it.

[1] [https://babun.github.io/](https://babun.github.io/)

------
Demiurge
I still use Windows SUA for my unix needs on Windows. It allows me to do most
things and provides real POSIX (except fork), but stuff like sensitive
filenames and unix style permissions actually work with NTFS. OpenSSH runs as
a real service, and so on. I don't understand why this subsystem never got
much recognition and suacommunity.com is even dead now...

~~~
pjmlp
Originally Windows had the concept of personalities and three were available
Win32, OS/2 and POSIX.

OS/2 went away, as soon as, OS/2 stopped being relevant.

POSIX was there mostly to get the foot into the door of US government, due to
its requirements in POSIX compatibility.

I guess when this stopped being required and Win32 was accepted as viable
platform, there wasn't a business case to keep on spending resources in POSIX
support.

After all, Windows is not alone in lack of full POSIX support when one looks
to embedded and mainframe OS as well.

~~~
Demiurge
It's deprecated now, but it is still there in Windows 8, and can be used for a
lot of things not even possible in 'build to win32' scheme.

~~~
pjmlp
I thought it was fully removed in 8, but I am yet to upgrade.

------
devniel
I have been using Gow almost three years, it's a great tool !

------
tonyplee
Has any tried busybox for Windows?

How is that compare to Gow?

