Live data from Hacker News

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

code.google.com

51–60 of 96 posts

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

#51
post #25

Or just use Far Manager - http://www.farmanager.com - it's Midnight Commander, Norton Commander type of program.

I've watched numerous Russian colleagues use it and it does not look appealing. These same colleagues do not seem to understand the power of a real *nix shell. You end up doing less typing if you really know your shell and how to pipe etc.

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

#52
post #38
post #5

Earlier quoted context omitted.

starts too slow.

on my PC it is instantaneous, it is a matter of hardware.

No, it's not. I have a TI6x laptop, 4gb of RAM, plenty o' CPU and with no other user-space programs running, it still takes FOREVER to start. I feel like i'm launching Eclipse or something.

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

#53
post #48

Earlier quoted context omitted.

The only thing that I find sucks is that the pipeline is slow as snails. This is because CreateProcess in Windows is slow. It's the reason that run make on Cygwin on Windows for not-that-large Makefiles is really, really slow. The same Makefile on UNIX and Windows differ in startup time by a wide margin. It's really painful to type "make ..." and sit there for 30 seconds on a fast machine.

CreateProcess is only being called once in this case i.e. to spawn svnadmin. The exact script does the following: svnadmin dump d:\repo > repo.dump The output from svnadmin has a lot of lines. Due to the fact that PS is written on top of the CLR, it reads each line into an immutable string before writing it to a file. So for every line it has to create a new System.String object and as another poster said GC it later…

I can appreciate the technical explanation as a programmer, but as an end-user of PS: I don't care. It's slow.

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

#54
post #38
post #5

Earlier quoted context omitted.

starts too slow.

on my PC it is instantaneous, it is a matter of hardware.

it is not a matter of hardware. On my ex-work desktop (2.8GHz quad core, so fairly quick) it used to take a good 5-10 seconds to be ready from a cold start. Yes, subsequent starts were faster, but it's a flipping shell, it shouldn't need hefty hardware to start quickly!

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

#55
post #41

Earlier quoted context omitted.

May I ask why?

Many a times, Microsoft will retire the older methods for something blazing new, and ruin what application knowledge you had in the process. These jumps in "technology" are perhaps forward, but also very much backward. I've seen it time and time again with clients who have bought a new computer and had to deal with growing pains (and hatred) of the blue globe, ribbons, and other 'we changed the gui to make it hard to…

If we're speaking strictly in regards to UI, then this is not a problem unique to Windows. I mean, would you not agree that Ubuntu's implementation of Unity changed the GUI a considerable amount compared to previous versions?

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

#56
post #55

Earlier quoted context omitted.

Many a times, Microsoft will retire the older methods for something blazing new, and ruin what application knowledge you had in the process. These jumps in "technology" are perhaps forward, but also very much backward. I've seen it time and time again with clients who have bought a new computer and had to deal with growing pains (and hatred) of the blue globe, ribbons, and other 'we changed the gui to make it hard to…

If we're speaking strictly in regards to UI, then this is not a problem unique to Windows. I mean, would you not agree that Ubuntu's implementation of Unity changed the GUI a considerable amount compared to previous versions?

The difference is that in the world of GNU/Linux, a different desktop environment or window manager is usually just a single package manager command away. You're being free to choose. Microsoft will force their UIs on you, and there's nothing you can do about it (except not updating, which is a workaround, not a solution).

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

#57
post #41

Earlier quoted context omitted.

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.

May I ask why?

Because lock-in is the only reason Windows is still so heavily entrenched on the market. This isn't even about the merit of Powershell as a program. This is about a tool which is designed to work on Windows (and Windows only[1]), and thus to increase the strength of the chains that bind you to the operating system.

Ever wondered why Microsoft didn't just make a bash-compatible shell? It's not like they couldn't - it's that they don't want. It would make it easier for people to jump ship, after all. And that's something they hope to prevent.

[1]: Yeah, yeah, there's a PS port to Unix land, but no sane human being will seriously use that. It's pretty much just another waste of time to save people from their mistake of investing into a proprietary tool tied to a proprietary environment.

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

#58
post #24

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

Except you can't change your default shell to it, and expect your system to work. You also can't expect that it's installed by default.

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

#60
post #9
post #7

just use cygwin

I feel like cygwin manages to combine the worst of UNIX and the worst of Windows. And the commands that use the cygwin runtime are noticeably slower than the native counterparts. Also, AFAIK there is no 64bit version yet, which for me is a dealbreaker (I often work with files larger than 2GB).

When I sometimes have to work in Windows (which really makes no sense at those companies since the products I build 99% of the time run on Linux); Cygwin makes Windows usable.
Post reply on HN