Live data from Hacker News

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

code.google.com

91–96 of 96 posts

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

#91
post #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.

Not sure why I'm getting hate for this. If you want to write a client for MSOffice365 you have to be on a Windows machine... and its a web-based "cloud" service. Makes no sense if you ask me.

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

#92
post #38

Earlier quoted context omitted.

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.

Try it on a T410, i7 with 8GB of RAM and a SSD, it takes 2s to start.

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

#93
post #87

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…

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…

You're only talking about all the trivial stuff, the IT setup, getting drivers to work with different hardware. This is the just the same on windows, except it has a much broader support for more hardware.

Of course things like config files change, but unix remains one of the most backwards compatible platforms to build anything on.

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

#94
post #93
post #87

Earlier quoted context omitted.

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…

You're only talking about all the trivial stuff, the IT setup, getting drivers to work with different hardware. This is the just the same on windows, except it has a much broader support for more hardware. Of course things like config files change, but unix remains one of the most backwards compatible platforms to build anything on.

Did you only read a few words of my post? How about binary (or even source code) compatibility with everything that is not POSIX (which is most of what a modern application needs), desktop environments, the very ways that applications interact with the user? (where files and data are stored etc.) What else is there? Sure, man 3 printf may have had the same interface for 30 years, but it's disingenuous to use that to claim that it's "the most backwards compatible platforms to build anything on".

What's even more funny is that you use "Unix" instead of "Linux", implying that software written for one Unix would magically work with others (I mean, that would be case if all was backwards compatible, right?). Have you ever written software for more than one Unix, even disregarding historical versions? The most painful concoctions needed to develop for several Unixy OS's (like, say, autotools) exist for the exact reason that they're not compatible at all. While at the same time, I've written code for Win98 almost 15 years ago whose binaries still run, without as much as changing a software setting, on Windows 7 (and probably 8 although I haven't tried) today. (again, there are plenty of things to critisize Windows for, but backward compatibility is not one of them).

"Of course things like config files change"

Yeah, that's like saying "of course a 2012 BMW is different in a few minor ways from a Model T, but essentially they're just machines with engines and wheels." Eh, yeah, sure.

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

#95
post #92

Earlier quoted context omitted.

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.

Try it on a T410, i7 with 8GB of RAM and a SSD, it takes 2s to start.

it's a SHELL for God's sake! I shouldn't need 8GB and SSD!!!

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

#96
post #89

Earlier quoted context omitted.

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

Good for you. As long as we're making up numbers: I can get 100% of what I need done in 80% of the time as you, simply because I use superior tools that eliminate menial labour. Get out of your bubble.
Post reply on HN