Live data from Hacker News

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

code.google.com

61–70 of 96 posts

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

#61
post #31
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…

> it means the output of one command goes to the input of another command as "objects".

Only if both commands support objects. If one of them doesn't then PowerShell just deals with text. I've sent the output of PowerShell commands to perl scripts and GNU utils without any problems. It just worked. I'm still a powershell newbie, and this has made it easy for me to learn it while still using what I know.

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

#62

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

It couldn't replace the command prompt because of security issues. Basically it made it very easy for virus writers to run powerful commands that the OS would blindly run. In response, Microsoft not only made scripts not executable by default, there is also a "signing" thingamajig where a script won't be executable unless it is specifically signed off to run[1], including those written by you.

[1]: http://www.hanselman.com/blog/SigningPowerShellScripts.aspx

It also isn't a drop in replacement for the command prompt. They exist as two separate programs, instead of the Unix general Terminal and shells run inside.

In my experience, Powershell has a lot of potential but is hampered by clunky interfaces and the lack of a true robust security system across the OS. Add on top of that the large malware industry around Windows, Powershell is basically a non-starter as a replacement for the vanilla command prompt.

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

#64
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…

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

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

#65
post #48

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!

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.

[deleted]

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

#66
post #24

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

Powershell is retarded. Microsoft uses it for their "web services" too which defeats the entire fucking point of it being a web service.

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

#67
post #49
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 do only easy things with Powershell and I found it much nicer than classical shells. It's more consistent in the command names and parameter passing. You also need to learn far fewer commands, because Powershell follows the Unix philosophy of small tools that do one thing well much more than Bash+Unix tools. For example if you do "ls" then you get a table where one of the columns is LastWriteTime. Want to sort by t…

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.

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

#68
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!

[deleted]

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

#69
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!

perhaps the real solution to the performance issue you mention is to have svnadmin actually write to a target file instead of crossing process boundaries to redirect stdout ?

have you tried :

Start-Process '{PATHTOSUBVERSION}\svnadmin' -argumentlist "dump {PATH_TO_REPOSITORY}" -RedirectStandardOutput c:\temp\repodump.dmp -Wait

more examples here : http://www.youtube.com/watch?v=9sn2L0E5jT8

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

#70

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.
Post reply on HN