Making a better, prettier, more functional Windows Command Line
hanselman.com
hanselman.com
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.
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.
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?
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.
For tools, the stuff from the GnuWin project fits into a cmd shell better than Cygwin (in my experience anyway):
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.
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 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.
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 :).
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.
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.
[1] : http://en.wikipedia.org/wiki/Interix [2] : http://en.wikipedia.org/wiki/Windows_Services_for_UNIX
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.
Here's mine in action http://i.imgur.com/S5mkXq6.png
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.
Try this iTerm2 :)
You can also configure it to start in a tab
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.)
# tab key: cycle through the list of partial matches
bind "\C-I":menu-complete
# ^p: traditional completion
bind "\C-p":complete TAB: menu-complete
"\e[Z": "\e-1\C-i"
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 user@example.org' and be on your way, but not so on Windows. Sigh.
--comment on the post
Really? Maybe he means in the Windows world.
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.
Your last sentence is confusing to me. RDP supports ClearType, and lossy compression is disabled by default (and only arrived in what, 2008 R2?.)
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'.
Let me restate GP's question: "Why do all Windows consoles use crazy thick fonts by default?"