Windows has indeed missed the text-mode boat big time. Eventually I think people naturally gravitate to running Linux with Windows in a virtual machine. I remember trying many of the tools mentioned in the article and it always never quite felt right. A lot of the niceness could be attributed to a combination of bash, readline, and the accompanying *nix tools--the experience just isn't the same in Windows. Having terminals open in front of you in something like terminator is simply a joy in Linux.

I think this lends heavily into the reasons why development on OSX has become so popular. Devs were dying for a functionally attractive alternative to Linux, but Windows didn't offer the proper environment.

Heck, as a primary Windows user I've been contemplating switching to OSX for development.

P.S. While Cygwin is nice, I've always felt like it was a clunky alternative that was shoe-horned into Windows.

Cygwin is my primary means of interfacing with Windows, and combined with a bunch of shim scripts I've built up over the years, I get a very similar experience across Windows, Linux, OS X and Solaris.

I actually prefer a Cygwin terminal on Windows to a Rxvt or similar lightweight terminal in X Window. The biggest pain in Linux is the selection buffer. With Console2 on Windows, selecting text puts it in the clipboard buffer, and you can then select a bunch of text in your IDE and overwrite it with a paste. The same workflow doesn't work at all well in Linux; first you must delete the text in the IDE, then select the text in the console, then very carefully aim where you want the text inserted and fire with the middle mouse button.

Even worse, IDEs like RubyMine clobber the selection buffer for common operations like Ctrl+Shift+N (Navigate | File); not only does it clobber the buffer, but it hides the window if it loses focus, so it's actually impossible to copy text from an rxvt terminal into its search box!

As a practical web development environment, I think Linux is the way to go to minimize the distance to production. But my preferred means of interacting with Linux is ssh, either to a VM or over the network, from a nicer desktop OS. Which for me is Windows.

> Cygwin is my primary means of interfacing with Windows...

Could you explain that a little more? For instance - say you want to browse the web or read email - you're doing it in a Cygwin terminal?

Do you use it as your launcher to launch Windows apps or do you only run text interface applications? Or, do you just do most of your dev/sysadmin work in Cygwin and use normal Windows apps for the rest?

I mean I have 7 terminals (many also running screen) open on my desktop - more windows than all other apps combined; and almost all interaction with the OS, by which I mostly mean process and file management, is via the command line. My browser is relegated to a secondary window alongside my service monitoring and ssh terminals.

When I write new utilities, they are usually command-line based. If I can get away with it, I'll put together a bash script built out of pipelines of Unix utilities and various others I've written over the years. I'm reluctant to write for-purpose apps; I try to make them fit into a Unix-style paradigm of streams combined with some command-line options.

For example, I recently wrote a simple video editor to select clips from my motorbike commuting videos. The only platform-specific bit is the video player, and all it does is respond to keyboard commands to navigate backwards and forwards and mark positions, in response to which it writes out text to standard out. I have other scripts which drive ffmpeg or other utilities as necessary to do the heavy lifting of cutting and composing. And to port it to another OS, all I need write anew is a video-playing component. And things like parallelization for efficiency, process isolation for resilience, and job control to temporarily reduce CPU usage (perhaps to avoid overheating on reencode!) are trivial.

For work, all my testing is done from the command-line, much of the code tweaks, all source control, merge resolution, grep / sed / etc. Debugging is usually done with repls like pry for Ruby. Browser at work is primarily used for distraction while having a coffee and waiting for tests to run, or to interact with company web apps.

Things like web browsers (Firefox in my case, because of tree-style tabs more than anything else) are invariant across platforms. If you live entirely in the browser, you don't need to deal with, or even know anything about, the machine's OS. So I don't really consider that use case an interaction.

Wow, that's impressive! I just couldn't imagine working that way, so thanks for clarifying.

Cygwin is strapped on the back of Windows or something. It doesn't try to fit in or play along (which is fine, it's a portability layer).

For tools, the stuff from the GnuWin project fits into a cmd shell better than Cygwin (in my experience anyway):

http://gnuwin32.sourceforge.net/

Yep, Cygwin is good if you have no other options, but it's like running Wine on Linux, i.e. some things might work but it's not surprising if they don't work (or work the way they should).

Agreed about Cygwin. I used it for years out of necessity, but I don't like when people suggest it as a remedy for Windows's anemic command line. Cygwin adds a tiny amount of what is needed. For one thing, Cygwin can't do anything about the terminal emulator, which is very weak.

Are you using MinTTY or the native cmd.exe-like terminal? MinTTY is based on PuTTY code and is quite reasonable (and a major improvement over the standard Windows way.

I've recently dumped my Windows environment. Switched from a massive powerful tower with multiple monitors to a single Macbook Pro Retina 15". My workflow is much faster now due to gestures and learning hotkeys, much more portable, works better, faster than my desktop. I can work remotely anywhere I want too which is amazing.

OS X is great for development. Besides gaming, I really don't see a point to using Windows ever again really. The UI is so much nicer, gestures save me a lot of time (quickly launch an application, view desktop, switch between spaces), combined without having to do any workarounds (working remotely on a Linux server) to get things running. Love having a native terminal as well.

Yep, I've been advocating running a headless nix VM on Windows for a while now, where you can easily 'shoosh' in (as Hanselman likes to call it - never heard this before myself).

The problem comes when you want the *nix tooling to interact with the Windows environment. Personally I like the clear separation between the host and guest environments, but YMMV. At the very least you can mount some share the Windows host provides inside the guest OS.

I've used Vagrant for this, and it works pretty well, including sharing directories between the host and guest. But of course you don't get to run Windows programs from within the VM, you only get to manipulate Windows files with Linux programs. So it's not a 100% substitute for a Windows shell.

Cygwins not bad if you just want a shell. It does Xorg too, but it's not fantastic. The main problem is not all programs will work on it (no tmux, but screen is ok), or be in the repos (I actually made an attempt to get Arch's makepkg/pacman working on it, but quite a few deps wouldn't compile properly, gpgme failed tests for example).

I think it would be great to have a tightly integrated VM. There are some that allow you to open Linux X apps in a Windows desktop rather than confined to a VM Window.

Perhaps we could get a Wayland/Mir port for Windows. Run the VM in the background but have a full Linux desktop environment. Might need a shim layer or some remote desktop extensions.

I think a lot more people run Linux as a guest than the other way around.

Yes, I would guess the same. However, I think people see it as a very big leap to jump over or the percentages would be different. Gaming, drivers (not as big a problem these days) and other specialized software also factor into this.

The way I see it is that if you're working with code, especially open languages and platforms, Linux is a great fit and you should make the leap :).

It's extremely telling that in the link to the Quine posted a few days back, the README listed a single apt-get command to install compilers/interpreters for 52 different programming languages. It's one of the reasons I love Linux (Debian in particular) - there's just so many toys included, not just for programming, but sys admin and science as well. Who needs games when you have that kind of power at your fingertips?

I definitely don't need games either. The other thing is that Windows is very graphical by default (understandable given that they are targeting the masses) but there isn't a built in way to make its presentation minimal[1], like stripping everything out and simply being able to launch what you need. This is easily achievable with a basic Openbox setup, with dmenu on top, boom!

1. There are probably customization tools out there that would let you get close to this but I don't believe it's truly possible just given desktop Windows' architecture.

I had the impression that cmd.exe was on its way out, soon to be replaced by Powershell entirely.

When I saw the option for Powershell to open by default in Windows 8/2012 instead of cmd.exe, I figured the writing was on the wall.

Powershell still uses the same terrible terminal emulator that cmd.exe does. This article is mostly about terminal emulators, and using windows shells for unixy stuff. Its not cmd.exe sepcific, I use Console2 for powershell terminals at home.

The Windows console isn't a terminal emulator, though, and never tried to be (ansi.sys notwithstanding, as that was a DOS remnant). I guess what most people actually want isn't a terminal emulator (which is kinda useless with the Windows Console API anyway) but just the nicenesses of a resizable console they have come to expect on Linux.

I find Conemu[1] even better than Console2. It's very configurable, and I think it's actively developed.

[1]https://code.google.com/p/conemu-maximus5/

I wonder if its time for microsoft to think about supporting a unix userland.

They already do/did [1,2]. Curiously there used to be a POSIX subsystem (alternative to Win32) but that was removed in favour of SUA.

[1] : http://en.wikipedia.org/wiki/Interix [2] : http://en.wikipedia.org/wiki/Windows_Services_for_UNIX

Services for UNIX has been deprecated. It is no longer being kept up-to-date with new Windows versions.

That's because the primary purpose of these tools was not to provide a UNIX environment for users. Rather, it was to provide a transition to Win32 for developers of UNIX applications. In version 1, you'd move the UI over to Windows, and leave the back-end mostly unchanged. In version 2, you'd then rewrite the back-end for the Windows API.

At this point, if you haven't already ported to Win32, then you're probably running on Linux.

Was about to mention Interix. I consider what Microsoft did with them to be truly a cautionary tale.

A properly configured ConEmu is pretty much the same as Linux terminals. It has tabs, transparency, background images, colors, proper copy paste, path autocompletion. What's missing ?

Here's mine in action http://i.imgur.com/S5mkXq6.png

Does conemu work right with applications like python? One common problem with layers over the console subsystem is that it's not possible for an application to detect that it is being manipulated by an interactive console anymore, because the layer over it (console2, mintty, etc) looks like a pipe.

To be fair, I haven't tested this out in a while, so maybe they fixed it. But last time I tried, python would see that pipe and assume you were piping a .py file into it instead of launching the interpreter. IIRC the problem is related to how 'isatty' works on win32.

At least Console2 isn't a pipe but instead polls the screen buffer of the invisible console window of the guest application. But could be that things have changed by now.

Is that Bug.n for tiling?

Yes, that's bug.n

Tip: You can run any graphical app as a tab in ConEmu. There's really no need for BitVise. You can run PuTTy and even Sublime inside a tab AND initiated from command line.

Try this iTerm2 :)

http://i.imgur.com/FWigyp6.png

Hey, that's cool... how did you configure that?

If you are asking about attaching GUI applications to tabs, there are a few ways to do that: https://code.google.com/p/conemu-maximus5/wiki/LaunchNewTab#...

You can also configure it to start in a tab

I always have this feeling, that console is more about tools that you can run (such as unix commands), than just some console improvements (like command history, copey-paste, etc.). I think the article focuses more on the latter.

Anyway, for people who really need some linux tools, cygwin is some viable option.

For hardcore hackers, I'd run an instance of colinux. you can the whole linux environment within windows with almost no performance overhead. (don't forget to configure "cofs" for windows files access.)

Doesn't coLinux rely on using a device driver to give the Linux kernel a dedicated chunk of physical RAM? Not quite overhead, but worth considering.

Personally I love the "cycle through the options" of the Windows Command Line. It's the one thing that I wish bash could emulate, instead of the "Show me all the options". For me, it's a lot more functional, because it doesn't require me to figure out what the differences are between file names. For example, trying to find the difference between R0BCRWPY_1373654012 vs R0BCRWPY_1373647568 is very tedious, especially if you have a bunch of similarly named files.

It's possible in bash too. In your .bashrc:

    # tab key: cycle through the list of partial matches
    bind "\C-I":menu-complete

    # ^p: traditional completion
    bind "\C-p":complete

Also, I have my Shift-TAB bound to menu-complete-reverse. The way I got it to work is to chuck these two lines into ~/.inputrc

  TAB: menu-complete
  "\e[Z": "\e-1\C-i"

The second line is the non-obvious one, can't remember where I found it. I wasn't able to get this to run unless it was in .inputrc though.

I'm spoiled using IPython on Linux. Even the latest PS IDE on Windows 2012 is a infant compared to the CLI tools on a Unixy OS.

Another nice terminal emulator for windows is MobaXterm[1]. It comes a single exe and has out of the box support for connecting to remote servers using a number of protocols.

One of the features I like is its builtin support for X-forwarding. I never quite got why Windows didn't (and still does not) come with a full-featured SSH client. On a Mac/Linux host, you can simply type 'ssh -X [email protected]' and be on your way, but not so on Windows. Sigh.

[1] - http://mobaxterm.mobatek.net/

I'm surprised Emacs was not mentioned. It provides a nice cross-platform interface to ... everything. Also everything (including looks) can be customized!

As someone who practically lives in Emacs running in Cygwin, I can second this, with some caveats: there are tradeoffs. Windows FS access and process forking are still dog-slow, even in native apps. To add to that, there are things I can't run in the native version of Emacs (w3m-el comes to mind), but you trade occasional lockups in Cygwin Emacs. Compare Linux where I run the same setup for Emacs for months if not years with no problems; even if Cygwin Emacs stays up that long, I will eventually (usually every week or so) be forcibly rebooted for Windows updates. If I never have to work with proprietary software again (especially Microsoft products), it will be too soon.

"Putty has always been the gold standard of terminals, for me."

--comment on the post

Really? Maybe he means in the Windows world.

Why do all Windows consoles use crazy thick fonts? It always seems weird to me, as someone weaned on xterm.

For one, they are bitmap fonts, based on what you'd usually see in video hardware ROM. Using a thinner font would cause DOS applications (the first, and main thing you'd run in a DOS box) to look really bad. Remember they would use things from the (character set)[http://en.wikipedia.org/wiki/Code_page_437] to do windows and such in text video modes.

In the current day, the non-bitmap fonts such as Consolas don't translate well when using things like RDP or other remote tools. Partially because you lose things like font smoothing which make them more readable and partially because of compression artifacts obscuring characters.

Almost all Linux distributions without an Android userland have a nice selection of bitmap fonts that are noticeably thinner. I've never noticed ill effects in curses applications.

Your last sentence is confusing to me. RDP supports ClearType, and lossy compression is disabled by default (and only arrived in what, 2008 R2?.)

This is probably the answer you're looking for:

http://blogs.msdn.com/b/oldnewthing/default.aspx?PageIndex=2...

TL/DR; The font has to support all the needed characters, plus not have have overhang etc which keeps the font from 'going outside the box'.

You know the cmd and ps fonts can be changed, right?

Fine.

Let me restate GP's question: "Why do all Windows consoles use crazy thick fonts by default?"

Because they had to pick something and you can't please anybody ever when picking typefaces?

Powershell is really quite good if you don't mind learning a slightly different shell. And there are good tools to extend it (PowerGUI is one I like).

Powershell on ConEmu is a joy to use, especially after you add in posh-git. When I found out Powershell can instantiate and call .net objects and functions (including threads) I immediately set out to convert all my batch scripts to powershell scripts and haven't looked back.

Nice! Thanks.

ISE on Powershell 3.0 is also somewhat useful

Whatever happened to DOSSHELL?

Windows doesn't run on top of DOS anymore, and with that, DOS Shell was deprecated in favor of the command emulator.