5 ms·

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 muc

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).

jamespo 12y ago
Probably because they want something to work with their windows tools
- gfodor 12y ago
  Yeah exactly, some of us are forced to develop software on windows (game development for example) so cygwin is a nice way to reduce some of the pain.
roxtar 12y ago
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.
- quotemstr 12y ago
  Plus you can run nmake and cl.exe directly from Cygwin bash and everything works just fine.
- UnoriginalGuy 12y ago
  > 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/speeding-up-powershell-startup-updating-update-gac-ps1.aspx 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.
  - roxtar 12y ago
    >> 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 :)
    - UnoriginalGuy 12y ago
      > 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 http://technet.microsoft.com/en-us/library/hh849925.aspx
      - roxtar 12y ago
        Thanks for the pointers and the link.
    - staticshock 12y ago
      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-basicsndashobjects-and-the-pipeline.html http://www.darkoperator.com/blog/2013/1/28/powershell-basics...
diltonm 12y ago
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.
Elrac 12y ago
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.
jqm 12y ago
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.

jamespo 12y ago

Probably because they want something to work with their windows tools

gfodor 12y ago
Yeah exactly, some of us are forced to develop software on windows (game development for example) so cygwin is a nice way to reduce some of the pain.

roxtar 12y ago

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.

quotemstr 12y ago
Plus you can run nmake and cl.exe directly from Cygwin bash and everything works just fine.
UnoriginalGuy 12y ago
> 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/speeding-up-powershell-startup-updating-update-gac-ps1.aspx 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.
- roxtar 12y ago
  >> 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 :)
  - UnoriginalGuy 12y ago
    > 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 http://technet.microsoft.com/en-us/library/hh849925.aspx
    - roxtar 12y ago
      Thanks for the pointers and the link.
  - staticshock 12y ago
    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-basicsndashobjects-and-the-pipeline.html http://www.darkoperator.com/blog/2013/1/28/powershell-basics...

diltonm 12y ago

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.

Elrac 12y ago

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.

jqm 12y ago

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.