Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

code.google.com

Post reply on HN
Print view View original

31–40 of 96 posts

Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

#31

Post by Graphon »

ehosca wrote: post #24

Do yourself a favor, learn PowerShell if you have to work on Windows. http://technet.microsoft.com/library/bb978526.aspx

While powershell is a valuable and interesting option, the problem with it is that it changes the basic metaphor.

For 40 years unix shells and their descendants and derivatives including cmd.exe have used files and text streams as the metaphor for interconnecting processes. Powershell changes that, and it means the output of one command goes to the input of another command as "objects".

This can be powerful, but it is also very disorienting. Which means it can be hard to learn to do even basic things in powershell, things that would take only a pipe or two and a couple unxutls programs in cmd.exe.

In cmd.exe, easy things are easy and hard things can be really hard. In powershell, hard things are hard (as opposed to "really hard") and easy things are hard.

Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

#32

Post by gouranga »

Graphon wrote: post #31
ehosca wrote: post #24

Do yourself a favor, learn PowerShell if you have to work on Windows. http://technet.microsoft.com/library/bb978526.aspx

While powershell is a valuable and interesting option, the problem with it is that it changes the basic metaphor. For 40 years unix shells and their descendants and derivatives including cmd.exe have used files and text streams as the metaphor for interconnecting processes. Powershell changes that, and it means the output of one command goes to the input of another command as "objects". This can be powerful, but it i…

I'm not a fan of powershell but I have to use it in my line of work.

The only thing that I find sucks is that the pipeline is slow as snails. For example, an svnadmin dump piped to a file which takes 8 mins in cmd.exe takes 14 hours in powershell...

Apart from that it's bearable!

Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

#33

Post by cygx »

malkia wrote: post #27
EvilTerran wrote: post #10

Earlier quoted context omitted.

I'm with you there -- I find Cygwin starts slow and unstable, and then seems to rot at an astonishing speed, to the point where it's usually unusable after I've had it installed for a couple of months.

Windows lacks fork(), or at least it's not documented. To implement the Cygwin folks have to go through a lot of tricks to implement it. And one of them is rebasing all dlls to start at different addresses. There is a tool to rebase everything, and it's usually started after install. It's possible that after you have recompiled your own apps/dlls they might need rebasing too (speaking as a cygwin user, not developer)…

> Windows lacks fork(), or at least it's not documented.

The NT kernel supports forking, but the Win32 subsystem does not. Because Interix lives outside the Win32 subsystem, it can provide a proper fork() implementation, whereas Cygwin has to live with its somewhat brittle emulation.

Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

#34

Post by to3m »

mih wrote: post #28
pudquick wrote: post #23

Earlier quoted context omitted.

If you like unixutils, you might like GOW a bit more: https://github.com/bmatzelle/gow/wiki/executables_list https://github.com/bmatzelle/gow/wiki Kept up to date, every .exe (once installed) is self-contained (no external .DLLs) and portable to just about any Windows box I've run into. No Cygwin or MinGW installation required. Bash is actually available in the list (albeit an older version) if you really wanted "bas…

Thanks. I used to use GNUWin32 ( http://gnuwin32.sourceforge.net/ ), but this seems like a good alternative.

This was my thought too, but I pushed GOW to a lower priority in my to-do list after a comment in a recent thread that publicised it:

http://news.ycombinator.com/item?id=4085830

Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

#35

Post by slowpoke »

ehosca wrote: post #24

Do yourself a favor, learn PowerShell if you have to work on Windows. http://technet.microsoft.com/library/bb978526.aspx

Do yourself a favor and don't lock yourself even more into the Windows environment if you, for whatever reason, have to work with it.

Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

#36

Post by antidoh »

Graphon wrote: post #30
projectileboy wrote: post #11

Is this different from Unix Utils? Every gig I've ever been on where I'm forced to use a Windows box, first thing I do is load the Unix Util exes into some directory and add it to the path. http://unxutils.sourceforge.net/

Yes, it's different. UnxUtls gives you grep, tar, tr, gzip, and etc. Clink appears to give you shell command completion and history completion. They are complementary.

Which is nice, because you get fine grained control over which bandaids you put over cmd.exe. This basically gives you readline and not much else, and you don't have to install multiple possibly overlapping bandaids to get it.

Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

#37

Post by pjmlp »

gouranga wrote: post #32
Graphon wrote: post #31

Earlier quoted context omitted.

While powershell is a valuable and interesting option, the problem with it is that it changes the basic metaphor. For 40 years unix shells and their descendants and derivatives including cmd.exe have used files and text streams as the metaphor for interconnecting processes. Powershell changes that, and it means the output of one command goes to the input of another command as "objects". This can be powerful, but it i…

I'm not a fan of powershell but I have to use it in my line of work. The only thing that I find sucks is that the pipeline is slow as snails. For example, an svnadmin dump piped to a file which takes 8 mins in cmd.exe takes 14 hours in powershell... Apart from that it's bearable!

Really 14hours?!

Have you tried to change the way the dump is done?

Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

#39

Post by gouranga »

pjmlp wrote: post #37
gouranga wrote: post #32

Earlier quoted context omitted.

I'm not a fan of powershell but I have to use it in my line of work. The only thing that I find sucks is that the pipeline is slow as snails. For example, an svnadmin dump piped to a file which takes 8 mins in cmd.exe takes 14 hours in powershell... Apart from that it's bearable!

Really 14hours?! Have you tried to change the way the dump is done?

Well you can only pipe to file as the output is on stdout. We just ran it through cmd.exe instead. 8 mins is fine - it's a 12Gb repo.

I assume it's related to PS converting every line into a system.string.

Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe

#40

Post by EvilTerran »

barrkel wrote: post #13
EvilTerran wrote: post #10

Earlier quoted context omitted.

I'm with you there -- I find Cygwin starts slow and unstable, and then seems to rot at an astonishing speed, to the point where it's usually unusable after I've had it installed for a couple of months.

Cygwin doesn't rot. It doesn't automatically update, and nor does it self-configure, so there's nothing to cause the rot. I've never had problems like you describe. The biggest problem - and what I suspect is happening to you - is when you have third-party programs and utilities that interfere with Cygwin, most often by putting an older or newer version of cygwin1.dll on the $PATH (i.e. you may be using Cygwin as par…

"there's nothing to cause the rot"

The rot tends to set in as I install packages to Cygwin; the more I add, the slower and less stable Cygwin seems to become, to the point of taking tens of seconds to reach a prompt after opening. Make of that what you will.

"Also some antivirus programs can trip up Cygwin"

That could well be a contributing factor in my case.

Post reply on HN