Gow – The lightweight alternative to Cygwin(github.com)
github.com
Gow – The lightweight alternative to Cygwin
https://github.com/bmatzelle/gow/wiki
117 comments
I completely agree, Cygwin has real OpenSSH, well you can even run Gnome on Windows if you want; even as your main shell or I was doing that back in 2002 not sure it would work these days. Overall Cygwin can't be beat. If Gow has enough utility for folks who want to use it; that's cool but for me when I'm stuck using Windows for anything, Cygwin rocks.
I run cygwin X so that I can have the tabbed version of urxvt.
I ditched mrxvt long ago because of lack of Unicode support (though I did use it under Cygwin/X).
https://github.com/simonzack/urxvt-tabbed - is this the project you're using?
https://github.com/simonzack/urxvt-tabbed - is this the project you're using?
No, not an external project, just one of the "official" rxvt variants. I use the same one on linux as on cygwin/X.
rxvt-unicode-256color
I use it on cygwin at work because I use it on linux at home, because of the tabs (which are text-based and have nothing to do with whatever desktop environment it's running in), and because the 256 colors make it easier for me to distinguish different code parts in a colored text editing session.
The default terminal in cygwin is OK, but the small number of colors were really bothering me (old eyes).
As for unicode, I've displayed Japanese and other scripts in rxvt-unicode-256color just fine.
rxvt-unicode-256color
I use it on cygwin at work because I use it on linux at home, because of the tabs (which are text-based and have nothing to do with whatever desktop environment it's running in), and because the 256 colors make it easier for me to distinguish different code parts in a colored text editing session.
The default terminal in cygwin is OK, but the small number of colors were really bothering me (old eyes).
As for unicode, I've displayed Japanese and other scripts in rxvt-unicode-256color just fine.
Here we go: http://imgur.com/eRea4I2
The right terminal has two tabs open, and it shows unicode displayed in the last command.
This is on linux, it looks the same on cygwin (except it has window borders there).
The right terminal has two tabs open, and it shows unicode displayed in the last command.
This is on linux, it looks the same on cygwin (except it has window borders there).
FYI, the default terminal for Cygwin these days is mintty, which supports 256 colours.
Oh super, thanks. I'll have to try that out.
Wouldn't it be better just to use ConEmu and mintty? I looked at urxvt but the ConEmu+mintty combo had all the features I wanted and was more up-to-date than urxvt.
mintty doesn't have enough colors for my eyes.
I use conemu for my windows command shell. I have tried it to run a cygwin bash shell, but I recall there being some annoyances, don't remember what anymore.
But fundamentally, no, it wouldn't be better to run ConEmu and mintty, because urxvt is exactly what I like. :)
I use conemu for my windows command shell. I have tried it to run a cygwin bash shell, but I recall there being some annoyances, don't remember what anymore.
But fundamentally, no, it wouldn't be better to run ConEmu and mintty, because urxvt is exactly what I like. :)
Fair enough if urxvt is exactly what you like. Not sure what you meant by the colour comment though, both urxvt and mintty support 256 colours... http://superuser.com/questions/736873/enable-256-colors-for-...
I tried the above for colors in mintty, nice, thanks.
As for running mintty in conemu, it's still not quite right. If I figure it out, this will be what I recommend to people.
But for me, I like having urxvt the same at home on linux and at work in cygwin. I use urxvt's keyboard management of its tabs a lot.
As for running mintty in conemu, it's still not quite right. If I figure it out, this will be what I recommend to people.
But for me, I like having urxvt the same at home on linux and at work in cygwin. I use urxvt's keyboard management of its tabs a lot.
I disagree. Having gnu utils available from CMD is a God send. Sometimes a batch script is the right tool but you need the capabilities of something from gnu utils. It's much simpler to just invoke the tool than to rewrite the script as a windows flavored bash script you run from Cygwin.
Additionally you'll find a lot of scripting language libraries just wrap gnu utils and invoke commands using a sub shell. Being able to run those scripts/libraries from batch files or other windows processes without dealing with Cygwin is awesome too.
Additionally you'll find a lot of scripting language libraries just wrap gnu utils and invoke commands using a sub shell. Being able to run those scripts/libraries from batch files or other windows processes without dealing with Cygwin is awesome too.
Indeed. Cygwin is fantastic, but one must always remember: once you go there, you can never go back. If you mix native Windows binaries with ones from Cygwin, all kinds of weird things can happen. I mostly work with native Windows binaries from ezwinports nowadays, together with ConEmu, Eclipse and a native Emacs; I can use normal Windows paths and things Just Work. Granted, it's more cumbersome to set this up than just installing Cygwin, but people are working on that (see for instance: MSYS2 at http://msys2.github.io/)
> once you go there, you can never go back. If you mix native Windows binaries with ones from Cygwin, all kinds of weird things can happen.
I used that setup all the time and it worked fine for me. Mixing win32 and Cygwin binaries is the point of Cygwin, as far as I'm concerned.
I used that setup all the time and it worked fine for me. Mixing win32 and Cygwin binaries is the point of Cygwin, as far as I'm concerned.
Then you are a lucky man. Ever tried to work with MsysGit in a Cygwin shell? For starters, there's the CR-LF vs LF problem, which can screw you big time. Then there's the problem that Cygwin handles Windows paths differently from MSYS (C:\foo becomes /cygdrive/c/foo on Cygwin, /c/foo on MSYS, but that's just the obvious difference, filename handling is actually much more subtle). And then there's the stuff which you won't notice until it bites you, like for instance '.cmd' and '.bat' not being treated as executables in Cygwin.
> Then there's the problem that Cygwin handles Windows paths differently from MSYS
I don't use MSYS, but my Cygwin installs are rooted at C:\. Win32 path functions actually accept forward slashes as well as backward slashes as path separators, so often, Win32 programs interpret paths like "/etc/passwd" just fine (with the drive resolving to C:\).
LF-versus-CRLF is an annoyance, but I've always solved it by using wrapper scripts that invoke u2d and d2u to perform the proper translation.
I think I previously my "injob" utility. Thanks to your comment, I got around to putting it on github: https://github.com/dcolascione/injob
I don't use MSYS, but my Cygwin installs are rooted at C:\. Win32 path functions actually accept forward slashes as well as backward slashes as path separators, so often, Win32 programs interpret paths like "/etc/passwd" just fine (with the drive resolving to C:\).
LF-versus-CRLF is an annoyance, but I've always solved it by using wrapper scripts that invoke u2d and d2u to perform the proper translation.
I think I previously my "injob" utility. Thanks to your comment, I got around to putting it on github: https://github.com/dcolascione/injob
> Give mintty a shot: you'll never go back to conhost.
No, give cmder a shot: http://bliker.github.io/cmder/ I've tried mintty and cmder, and cmder was just perfect for me.
No, give cmder a shot: http://bliker.github.io/cmder/ I've tried mintty and cmder, and cmder was just perfect for me.
How does cmder compare to ConEmu?
https://code.google.com/p/conemu-maximus5/
https://code.google.com/p/conemu-maximus5/
It appears to be built on ConEmu. From the homepage:
> Think about cmder more as a software package than a separate app. All the magic is happening through Conemu. With enhancements from Clink.
> Think about cmder more as a software package than a separate app. All the magic is happening through Conemu. With enhancements from Clink.
Oh my goodness thank-you! I'm forced to use Windows at work, and this is the first terminal emulator that looks not terrible!
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
[1] https://github.com/babun/babun
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.
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.
But people would rather just hack up a "terminal emulator" instead of doing things the properly and the hard way.
[deleted]
I use Mintty because Cygwin's tmux didn't work with ConEmu or Cmder, but Mintty was ok.
FWIW, I took a quick stab at the tmux & ncurses code to try to find a fix, but it was far from obvious. Maximus (ConEmu author) said it had to do with how cygwin flags stdin streams, which just happens to break when ConEmu provides them. (sorry details vague)
FWIW, I took a quick stab at the tmux & ncurses code to try to find a fix, but it was far from obvious. Maximus (ConEmu author) said it had to do with how cygwin flags stdin streams, which just happens to break when ConEmu provides them. (sorry details vague)
Quickly scanning the code, it looks like ConEmu is using hooking to implement the Win32 console API and forward calls to the terminal emulator. That's a good approach, but it needs to be integrated into the Cygwin pty system to really work well in that environment.
The issue with Cygwin is that disk IO in particular is incredibly slow. Which makes things like git substantially slower than on Linux or OSX.
The problem isn't with disk IO as much as it's with speed of the stat() syscall. IIRC Cygwin stat() is backed by three different NT syscalls, so it's slow because it requires three transitions to kernel mode, where Linux only needs one. Setting core.fileMode to false makes Git use a Windows optimized version of stat(), so it runs a lot faster.
Unfortunately it's still not quite as fast as on Linux and OS X, but it's about as fast as native/MSYS versions of Git on Windows.
Unfortunately it's still not quite as fast as on Linux and OS X, but it's about as fast as native/MSYS versions of Git on Windows.
> three transitions to kernel mode,
It's not the number of "transitions to kernel mode" (which is actually really fast), but the cost of performing the UID mapping, especially considering that this effort is frequently wasted when programs don't bother inspecting st_uid and friends. That's why I wish the Linux xstat syscall, the one that let programs ask for just what they need, had gone through: it'd have made other systems more efficient too.
It's not the number of "transitions to kernel mode" (which is actually really fast), but the cost of performing the UID mapping, especially considering that this effort is frequently wasted when programs don't bother inspecting st_uid and friends. That's why I wish the Linux xstat syscall, the one that let programs ask for just what they need, had gone through: it'd have made other systems more efficient too.
Can't the UID mapping be cached.
MsysGit is still way slower than Git on Linux, at least on larger repositories. Calling stat() on lots of small files is pretty much a worst-case scenario for NTFS.
On Cygwin, I wonder if a SetCurrentDirectoryEx function would be a good idea: https://cygwin.com/ml/cygwin/2012-04/msg00632.html
A very convenient improvement that makes a difference is http://mridgers.github.io/clink/ (readline mostly). Tiny, useful, fresh air.
Oh, wow. I don't run windows anymore, but that's quite an amazing little tool. My work mates who use windows are going to be stoked with this, thanks. Currently they're all use cmder, but some struggle with the impedance mismatch of a GNU/NT system like that. This with native binaries will be an amazing setup!
Yeah, clink author hit the nail on the head. `Minimally Enjoyable Upgrade` I guess.
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.
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.
Was my experience with Cygwion itself 9 years ago or so -- broken beyond usable for anything except look-ma tests :)
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.
Yeah yeah. I opened this: https://github.com/bmatzelle/gow/issues/164
Please comment with clarifications.
Please comment with clarifications.
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.
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.
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.
> 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.
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.
"Most things are there, just done in very different ways."
Does it have something like the POSIX fork() system call? Apparently, its lack in Windows is the main thing that makes Cygwin as slow as it is.[1]
[1] - http://stackoverflow.com/questions/2512892/how-to-speed-up-c...
Does it have something like the POSIX fork() system call? Apparently, its lack in Windows is the main thing that makes Cygwin as slow as it is.[1]
[1] - http://stackoverflow.com/questions/2512892/how-to-speed-up-c...
Only UNIX clones support fork() properly, because only UNIX clones processes.
Any other non UNIX OS tends not to fully provide 100% fork() in they POSIX compatibility layer, or kind of fake it.
Any other non UNIX OS tends not to fully provide 100% fork() in they POSIX compatibility layer, or kind of fake it.
Sorry for the stupid question but does that mean you can't write C code in Windows that calls fork()?
I'm not really an expert but I'm pretty sure you can call fork but you will pay a full cost of a creating a new process, manually copying the memory state to the new process and parent and child have to do a complicated dance to ensure it all happens right. So it works and most of the semantics are the same, but it is god awful slow.
> you can call fork but you will pay a full cost of a creating a new process, manually copying the memory state to the new process and parent and child have to do a complicated dance to ensure it all happens right
That fork() and associated dance happens in cygwin1.dll or the equivalent POSIX compatibility library. Windows has no fork to call.
That fork() and associated dance happens in cygwin1.dll or the equivalent POSIX compatibility library. Windows has no fork to call.
You are correct, fork() is part of the POSIX specification, Windows does not implement POSIX.
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.
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.
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.
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.
telnetd ok, but telnet itself? What for? Crappy, slow, port scanning?
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.
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".
[deleted]
telnet and tfpt clients are still part of Windows, just not installed by default.
You need to go into Control Panel > Programs and Features > Turn Windows Features On or Off.
They, amongst other tools, are listed there.
You need to go into Control Panel > Programs and Features > Turn Windows Features On or Off.
They, amongst other tools, are listed there.
dig's never been distributed with any Linux OS I've used. (Resolve-DnsName is in Powershell 4.0, which implements most of that functionality.) Nor has lftp. So we'll take those out of the running.
The vast majority of what wget and curl are used for is simply downloading single files/pages. Invoke-WebRequest does that fine. It also deals with poking at most web services you're likely to come across. What service can't you use with it?
As for telnet... the removal of that was ridiculous, I'll admit.
The vast majority of what wget and curl are used for is simply downloading single files/pages. Invoke-WebRequest does that fine. It also deals with poking at most web services you're likely to come across. What service can't you use with it?
As for telnet... the removal of that was ridiculous, I'll admit.
Not the same user, but I once tried to get PowerShell to do an ls over FTP for me, and even with copying some sample code it was horribly painful.
I can't speak from broad experience but my impression was that PowerShell does a bunch of common cases fairly well but if you want something a bit different you're bashing your head on your desk.
I can't speak from broad experience but my impression was that PowerShell does a bunch of common cases fairly well but if you want something a bit different you're bashing your head on your desk.
> you're bashing your head on your desk
Repeatedly.
Powershell is a wonderful concept but the ecosystem around it, except for Microsoft's own extensions, hasn't really hit puberty.
Also try writing scripts which involve native Windows commands (such as robocopy & company). Things are definitely not intuitive and the error handling is crappy. You either stay within Powershell bounds and everything is wonderful, or you step out and are in a world of pain.
Repeatedly.
Powershell is a wonderful concept but the ecosystem around it, except for Microsoft's own extensions, hasn't really hit puberty.
Also try writing scripts which involve native Windows commands (such as robocopy & company). Things are definitely not intuitive and the error handling is crappy. You either stay within Powershell bounds and everything is wonderful, or you step out and are in a world of pain.
years ago I posted much the same sentiment on stack overflow when I was attempting to use Powershell 1 to build and deploy software that used SVN for it's SCM.
It was a pain in the neck and I felt like the PS integration was awesome as long as you stayed in that ecosystem, but the second you strayed... pain.
I got bashed fairly hard with the question I asked surrounding it closed as unconstructive (it was an honest question about exactly what PS was targetted towards).
It was a pain in the neck and I felt like the PS integration was awesome as long as you stayed in that ecosystem, but the second you strayed... pain.
I got bashed fairly hard with the question I asked surrounding it closed as unconstructive (it was an honest question about exactly what PS was targetted towards).
It only kind of has ssh. It has the PuTTY SSH client, but no SSH server.
> 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.
Others have already mentioned Powershell. Not by default, but Microsoft has offered Windows Services for UNIX for some time. Free download too: http://www.microsoft.com/en-us/download/details.aspx?id=274
Truthfully, I've never used it myself, because Cygwin exists and it actually provides full POSIX on Windows, unlike GOW et al.
Others have already mentioned Powershell. Not by default, but Microsoft has offered Windows Services for UNIX for some time. Free download too: http://www.microsoft.com/en-us/download/details.aspx?id=274
Truthfully, I've never used it myself, because Cygwin exists and it actually provides full POSIX on Windows, unlike GOW et al.
Supported OSes: "Windows 2000, Windows 2000 Service Pack 3, Windows 2000 Service Pack 4, Windows Server 2003, Windows XP"
They haven't updated WSfU for years now.
They haven't updated WSfU for years now.
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.
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.
The repo does not seem to have the source code, which is a bit of a problem as most of the software is GPL.
> 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.
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.
Well, that's kind of undiscoverable; it really ought to be on the shell extension context menu.
Much like Mac, Windows is designed for consumers primarily, power users/programmers/etc secondarily.
It can be reconfigured to appear without shift:
http://superuser.com/questions/240279/windows-open-command-p...
Although the Windows 8.1 right click bottom left for the new Power Users Menu was a welcomed addition that consumers could inadvertently run across.
It can be reconfigured to appear without shift:
http://superuser.com/questions/240279/windows-open-command-p...
Although the Windows 8.1 right click bottom left for the new Power Users Menu was a welcomed addition that consumers could inadvertently run across.
That was almost certainly the "Command Prompt Here" powertoy for XP, but it was then integrated into Vista and 7.
Yes, it was probably that. Some of those powertoys were cool.
I remember installing and using that one. Didn't know that it was integrated into Windows 7 with that Shift+Right-Click shortcut though, thanks.
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 ."
XP didn't have this feature. It was in Vista onwards.
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.
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.
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.
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.
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.
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
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)
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.
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)
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.
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/ and link in the CWSDPMI DOS extender from 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
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
What's the point over MSYS2?
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/
>"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.
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.
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.)
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.
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.)
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.)
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.
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).
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.
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.
Plus you can run nmake and cl.exe directly from Cygwin bash and everything works just fine.
> 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...
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.
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...
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.
>> 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 :)
>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 :)
> Can you give examples where PowerShell can do something which CygWin/MinGw can't?
As those contain full programming languages which can effectively do anything with enough effort I doubt I can.
I will say the DateTime, cultural conversion, and email libraries are an absolute pleasure to work with in Powershell/.Net. Sending out email is a totally trivial exercise regardless of the style (plain text, HTML, attachments, etc).
http://technet.microsoft.com/en-us/library/hh849925.aspx
As those contain full programming languages which can effectively do anything with enough effort I doubt I can.
I will say the DateTime, cultural conversion, and email libraries are an absolute pleasure to work with in Powershell/.Net. Sending out email is a totally trivial exercise regardless of the style (plain text, HTML, attachments, etc).
http://technet.microsoft.com/en-us/library/hh849925.aspx
Thanks for the pointers and the link.
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...
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...
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.
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.
> Downside: if you want to write a consumer, you're stuck in .NET land.
Powershell has access to the whole .NET features, meaning you can also expose DLL and COM objects into your Powershell session.
Powershell has access to the whole .NET features, meaning you can also expose DLL and COM objects into your Powershell session.
When you run ps on Cygwin on Windows you are seeing the actual Windows processes, everything you do in the shell is on the Windows machine. Without Cygwin; Windows IMHO is nowhere near as friendly, at the CLI. I can completely get along fine on Windows without Cygwin (when I have to run Windows) but it makes the experience tolerable to have it. It makes Windows like Linux at the CLI.
I use a set of Unix utils similar to the one mentioned in the post, just to do spiffy things in a CMD shell once in a while.
Other people have already mentioned that this is a much more lightweight kind of process than firing up a whole operating system in a VM. But more significantly, these utils are a bunch of .EXEs I can toss into a directory, possibly adding it to my PATH. Working (sometimes) on a "work" PC with no admin privileges, I think I can't install something like VMWare. I'd also worry about ending up with a big chunk of my memory chewed up as long as VMWare is running.
Other people have already mentioned that this is a much more lightweight kind of process than firing up a whole operating system in a VM. But more significantly, these utils are a bunch of .EXEs I can toss into a directory, possibly adding it to my PATH. Working (sometimes) on a "work" PC with no admin privileges, I think I can't install something like VMWare. I'd also worry about ending up with a big chunk of my memory chewed up as long as VMWare is running.
I took a job recently in a Windows ecosystem. I hadn't used Windows on a day to day basis in 4 or 5 years and my co-workers laughed behind my back as I stumbled around clumsily clicking buttons looking for the control panel.
The laughter turned to open mouthed jealous amazement when I installed Cygwin and started doing everything they were at 5X speed including remotely on the servers. (Yes, firing up remote desktop and clicking file icons is slow..... go figure!)
To be frank, Cygwin is the only reason I didn't walk out the door the first week. It's generally fantastic and has been a lifesaver. I get lots of guarded curious inquiries.
Windows is getting better, but as of right now, its still pretty clumsy comparatively. Powershell looks interesting but I don't want to take the time learn all the intricacies. Anyway, I'm pretty sure it would be years before I could get around as fast as I do with Cygwin. And that assumes equivelent functionality... which I doubt at this point. Some of my Vim settings (colors etc) didn't show up correctly in Powershell for instance.
So... that's why some people would use Unix shells in Windows.
The laughter turned to open mouthed jealous amazement when I installed Cygwin and started doing everything they were at 5X speed including remotely on the servers. (Yes, firing up remote desktop and clicking file icons is slow..... go figure!)
To be frank, Cygwin is the only reason I didn't walk out the door the first week. It's generally fantastic and has been a lifesaver. I get lots of guarded curious inquiries.
Windows is getting better, but as of right now, its still pretty clumsy comparatively. Powershell looks interesting but I don't want to take the time learn all the intricacies. Anyway, I'm pretty sure it would be years before I could get around as fast as I do with Cygwin. And that assumes equivelent functionality... which I doubt at this point. Some of my Vim settings (colors etc) didn't show up correctly in Powershell for instance.
So... that's why some people would use Unix shells in Windows.
[deleted]
I've been using Babun [1] and fully enjoying it.
[1] https://babun.github.io/
[1] https://babun.github.io/
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...
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.
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.
I've read about Windows SUA (and it's predecessors) but have never been sure what problem it solves for me.
Got a use case or two?
Got a use case or two?
I have been using Gow almost three years, it's a great tool !
Has any tried busybox for Windows?
How is that compare to Gow?
How is that compare to Gow?
Yes, there are some warts, but they're papered over remarkably well. Give mintty a shot: you'll never go back to conhost.