Or just use Far Manager - http://www.farmanager.com - it's Midnight Commander, Norton Commander type of program.
Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe
51–60 of 96 posts
Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe
#52Earlier quoted context omitted.
starts too slow.
on my PC it is instantaneous, it is a matter of hardware.
Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe
#53Earlier 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…
Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe
#54Earlier quoted context omitted.
starts too slow.
on my PC it is instantaneous, it is a matter of hardware.
Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe
#55Earlier 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…
Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe
#56Earlier 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?
Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe
#57Earlier 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?
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
#58Do yourself a favor, learn PowerShell if you have to work on Windows. http://technet.microsoft.com/library/bb978526.aspx
Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe
#59Re: Bringing Bash's powerful command line editing to Microsoft Windows' cmd.exe
#60just 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).