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

81–90 of 96 posts

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

#81

Post by gouranga »

DeepDuh wrote: post #64
gouranga wrote: post #50

Earlier quoted context omitted.

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…

That's when doing it the Enterprisey way bites you in the ass..

I don't understand your comment. There's nothing enterprisey about it.

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

#82

Post by gouranga »

noveltyaccount wrote: post #77
gouranga wrote: post #19

I've switched to powershell ISE on windows (shipped with it) rather than cmd hosted powershell. Does the job!

Have you tried the ISE on Win8 yet? It gets some nice upgrades around intellisense.

Not yet - will fire up my vm later. Thanks for the tip!

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

#83

Post by gouranga »

omaranto wrote: post #70
gouranga wrote: post #19

I've switched to powershell ISE on windows (shipped with it) rather than cmd hosted powershell. Does the job!

Is it worth installing .NET 3.5 to run the ISE? I use Powershell but only have .NET 4 which runs it just fine. I'm a little surprised that ISE requires 3.5.

It doesn't make any difference. It required 3.5 as win7 shipped with that framework. You may actually have 3.5 installed already. Check for the following dir: c:\windows\Microsoft.net\framework\v3.5

If it's there you have it already.

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

#84

Post by gouranga »

shortlived wrote: post #53
gouranga wrote: post #50

Earlier quoted context omitted.

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.

For the majority of tasks it's fast enough. There are a few edge cases though.

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

#85

Post by DeepDuh »

gouranga wrote: post #81
DeepDuh wrote: post #64

Earlier quoted context omitted.

That's when doing it the Enterprisey way bites you in the ass..

I don't understand your comment. There's nothing enterprisey about it.

I mean that from Microsoft's perspective. They apparently decided to put an object around something as simple and essential to performance as a line buffer. That's when you should have hired a system programmer to do that job.

Don't get me wrong, I actually like their approach in developing an OO-shell - but if it hurts performance that much someone has taken that paradigm too far. It's the typical case of someone with a hammer (OO programmer) trying to approach everything like it were nails.

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

#86

Post by gouranga »

DeepDuh wrote: post #85
gouranga wrote: post #81

Earlier quoted context omitted.

I don't understand your comment. There's nothing enterprisey about it.

I mean that from Microsoft's perspective. They apparently decided to put an object around something as simple and essential to performance as a line buffer. That's when you should have hired a system programmer to do that job. Don't get me wrong, I actually like their approach in developing an OO-shell - but if it hurts performance that much someone has taken that paradigm too far. It's the typical case of someone wi…

That's a fair evaluation and one I agree with entirely.

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

#87

Post by roel_v »

TheAmazingIdiot wrote: post #43
Permit wrote: 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…

LOL. You show me a Linux machine that runs 15-year old binaries without problems, or source code that old that compiles against a modern machine, or even just source code 2 years old, for that matter. I'm not a big Microsoft fan but saying that they're less backwards compatible than the alternatives is talk from the looney bin.

"At least in the Linux world, your knowledge isn't decimated on an update."

Of course, so that's why the time I put into learning how LILO worked is now paying off so greatly! Oh no wait it doesn't, because LILO went the way of the dodo (as far as I can tell, I don't use Linux all that often any more). Wait, all that time I used to spend on manually insmod'ing kernel modules to get my audio to work with the various audio systems, that has paid off! Hmm no, that too is a crapshoot that changes every year or so. Config file format? Different between all programs. Desktop integration? Different desktop systems, who each change how they work every 2 or 3 years. Gfx card drivers? Depends on the brand, make and (if you're lucky) distro. Networking setup? Lol, don't get me started.

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

#89

Post by alttab »

noveltyaccount wrote: post #75
alttab wrote: post #67

Earlier quoted context omitted.

Just one more way that ms produces developers that cant do anything on their own, or outside visual studio. Just my experience, but most ms developers have been crippled by their tooling. Powershell is no exception.

"Powershell makes it easier to discover commands" "You're weak and have been crippled by your tools." o_o You're suffering from Stockholm Syndrome. Upgrade your tools and be free from menial labor.

I disagree. All the time spent finding and learning new tools can be spent getting things done. I use bash, vi, grep, and man and I can get 95% of what I need done with just those.

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

#90

Post by coroxout »

forgotusername wrote: post #47
TheAmazingIdiot wrote: post #43

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…

My experience of Microsoft was that they're the most backward compatible source of technology around. Perhaps you could provide specific examples of breakage? It's funny that this should come up in a thread about PowerShell, a replacement shell Microsoft released 6 years ago which still hasn't supplanted cmd.exe (which itself is based on syntax from the late 70s).

In 1990 I used the MS-DOS 5 Edit tool and QBasic and picked up the shortcuts Ctrl-insert and Shift-insert for copy and paste.

I'm still using them 22 years later. They still work in most Windows applications and all MS applications even though they're not listed. They could easily have taken them out since Ctrl-C and Ctrl-V have been standard in Windows for so long, but they didn't.

I also got quite comfortable with using F2 and F4 to edit my previous DOS command, which still work in Command Prompt. And since Command Prompt now has tab completion and copy and paste, I don't really feel the need to add a bash-style command history. In fact I can never remember the bash equivalent of some of the cmd history shortcuts I use.

I have, however, installed the GOW package (see bmatzelle on github) for grep, less, wc etc at the command prompt. grep is so much faster than the MS equivalent "find" it's not funny, e.g. I just searched for a 9-digit number across 13 files containing 4 million lines (158MB) and grep took 1 second; find took 57.

Post reply on HN