Gow - A lightweight alternative to Cygwin
github.com
github.com
Cmder is a little slow by default, but faster if you disable the git branch in the prompt. Other people I know use Clink (http://mridgers.github.io/clink/), the library the powers the readline-like portion of Cmder.
Only problem is that Far's default configuration kinda sucks (LeftCtrl+4 is the first thing I do on a new install).
Another invaluable tool for Unix-y stuff on Windows is Rapid Environment Editor (http://www.rapidee.com/en/about), because the integrated editor for environment variables in Windows is just horrible.
Between MSYS, MINGW, Cygwin, Cmder, Clink, Babun, etc. I am just wildly confused in general. I've used linux, I've used windows. Admittedly I am blessed enough to stick with Python but I know that even Anaconda does some msys magic behind the scenes on windows as well.
I use Cygwin as my main interface on Windows, while my work machine is Linux. I've been using Linux since 96. There is very little functional difference between terminal-based userland on Cygwin and Linux, with the sole exception of speed; Cygwin syscalls are slow, and forking is to be avoided in shell scripts where possible.
Cygwin is a better Unix than OOTB OSX owing to not being stuck on GPL 2.
The use case for them is "I want a Windows shell that works exactly like Unix" or "I want to port a Unix program to Windows with minimal effort."
Cmder and ConEmu address a bunch of deficiencies in the Windows Console Host (conhost.exe) that provides the UI for all console programs on Windows. They add features like resizable and tabbed windows but behind the scenes they're running conhost in a hidden window and redirecting i/o.
The primary use case for Cmder and ConEmu is "I think the Windows Console Host sucks and want something better."
GoW is a collection of GNU programs compiled for Windows with no dependencies on Cygwin or MinGW. The use case is "I want a Windows port of some common Unix command-line programs without any extra baggage."
There are shells, environment, terms (ttys), package managers, and then there a bunch of emulation packages on windows.
Go back and read the docs for each tool to understand what it provides (shell, environment, terminal support, library, or package manager).
Clear as mud?
That's why I suggest trying linux again.
I maintain the most active fork and got into using it when I ported my last employer's software to Windows. This was originally developed in the early 1990s to run on Unix workstations. For portability it used Bourne shell (not bash) and nawk (not gawk). BusyBox allowed them to bundle a single executable with the Windows version that was adequate to run those scripts.
Some projects use busybox-w32 to allow a Unix-centric build system to work on Windows. Julia, for example, seems to use it just to get echo and printf.
I use it with ConEmu, and it goes a long way towards usability. I also use Clover as a file explorer wrapper/replacement. I usually have a couple browsers, editors/ide, clover and conemu open at all times.. tabbed interfaces are beyond useful.
As is having a bash shell (although some things aren't quite the same).
Moreover, using cross-platform Unicode-aware tools in (still not really Unicode-aware) cmd.exe will blow up sooner than later on “funny” filenames. As others said, you need proper shell and terminal.
This project is a Good Idea, but it would be overwhelmingly more useful if it tracked modern versions.
UnxUtils and DJGPP are other alternatives.
Speaking of which, this project has been posted on HN at least 4 times previously.
EDIT: No, they appear to be publicly available in Releases, as mentioned by another poster.
Both are out of date and distributed as binaries... What else? :)
Seriously though, if you fork the project and dump the tarballs into a branch, I'll check it out and run make. Or, I'll write a script that runs a bunch of individual makes. Whatever.
I like `UnxUtils` (and Gow) but this practice is not sustainable..
GoW is pretty much the same thing but not abandoned yet. Some things are definitely out of date, I end up pulling curl from elsewhere, but it provides most of the important things and they Just Work. Beats the hell out of using Cygwin.
> * Shell window from any directory: Adds a Windows Explorer shell
> window so that you can right-click on any directory and open a
> command (cmd.exe) window from that directory.
> * Simple install/remove: Easy to install and remove, all files
> contained in a single directory in a standard C:\Program Files path.
> * Included in PATH: All binaries are conveniently installed into the Windows
> PATH so they are accessible from a command-line window.
These three bullets seem contradictory, how can it modify explorer context menu and PATH by just adding files in a Program Files directory. Besides, the first bullet is already built into windows explorer without any add-ons, just hold shift while right-clicking and the option will appear.Overall the best long term option is to simply stop developing on windows and start using Linux, docker, mono, nodejs etc.
I did this 10 years ago, and the situation on windows still hasn't improved.
Also, how does node have anything to do with this discussion?
That's one of the reasons why I keep virtualbox around on my Windows box. I don't want any integration with the shell, I want applications to be self-contained and not spam on Windows as much as possible.
http://stefanstools.sourceforge.net/StExBar.html
The regex rename for multiple files is quite nice.
What's the size of a new cygwin install? Well it can be larger than 100MB, sure. It has lots of packages.
https://stackoverflow.com/questions/6498850/programming-lang...
libmingw if you want lightweight, msys if you want an env + mingw, cygwin if you want something with a nicer unix env.
No matter what env you have, if its on win it going to suck a bit.
Who frets about 100MB on their hard drive in 2015, and why wouldn't these mythical users just install only the cygwin packages they need?