Live data from Hacker News

How bad is the Windows command line really?

blog.nullspace.io

51–60 of 110 posts

Re: How bad is the Windows command line really?

#51

Personally, one of the reasons why I fell in love with Ruby 10+ years ago was because I realized I could use it instead of CMD or bash to write all my scripts from now on. Regardless of the platform. Obviously, this applies to Python as well if that's more your thing. I've never gotten into PowerShell but I have absolute respect for the concept behind it, and how much more advanced it is than any shell you can find o…

> you are now piping real language objects

Which is in fact a bad idea, because in order for stdin to accept objects and stdout to output objects, now those commands have to be powered by PowerShell and .NET. In other words you're in a very finite and closed environment that does not interoperate with the outside world.

You know, love or hate Unix, but the fact remains that this family of operating systems, including its command line, has survived the test of time. And it has done so because it has at its core a set of philosophical principles. And one of those is that programs that handle text streams are preferred, being highly interoperable, as text is a universal interface [1]. And you know it's funny how people loathe Unix, but at the same time rediscover its principles (and often implement them badly) again and again.

[1] http://www.faqs.org/docs/artu/ch01s06.html

Re: How bad is the Windows command line really?

#52
post #46

I honestly feel like I am missing something. What is the current excitement about bash on Windows? It's been available (and something I commonly use) via cygwin for years. And cygwin's bash can run .exe binaries.

Cygwin is quite slow due to problems emulating fork (large builds take forever!), plus the package support is spotty. I'm excited because I can eventually ditch Cygwin and VMs for much of my Linux compatibility testing and cross-platform work. And I'm glad Microsoft is finally putting some effort into this long-neglected area.

For the moment, I'm still stuck with Cygwin, shaking my head a bit too.

Re: How bad is the Windows command line really?

#53
post #39

Earlier quoted context omitted.

You can also normalize them using the dos2unix package, which is available on most distros.

Or just `sed -e 's|\r||'`.

If you just want to delete a character there's no need for sed. Just do: tr -d '\r'

Re: How bad is the Windows command line really?

#54
post #13

Powershell is garbage. .Net does utf8 by default but powershell, built on .Net, manages not to. Try type utf8Encoded.txt > out.txt in cmd.exe and posh. Cmd works and posh fs it up. And after you do figure out utf8 encoding in posh, it'll always add a BOM just to screw you

This has frustrated me to no end. I've given into using WriteAllLines as a work-around. [IO.File]::WriteAllLines($filename, $content) (from https://stackoverflow.com/questions/5596982/using-powershell... )

I get OOM with larger files even when they should fit in memory.

Powershell is like a poor Java/C# interpreter instead of a quick and dirty shell.

Re: How bad is the Windows command line really?

#55
It's really, really, really, really really bad.

It doesn't even have a logical history. Despite having used it for many years, I still don't understand why when I type one command (eg make), and then another (eg out.exe), I have to toggle between pressing up or pressing down from the new command-prompt to access the previous commands.

I can't make the window more than 80-characters wide dynamically. (I don't want to change settings and restart the program to get the width to change.) So any time I want to copy and paste one of the infamous wall-of-text C++ template errors, I have to waste a lot of time reformatting the text.

Copy-and-paste as well is just complete garbage that takes forever.

I have to dump batch files into a folder in PATH because there's no alias support nor .profile startup script.

I can't color-code the prompt separately for visibility. There's no tab-completion. There's no shell escaping backticks. On and on.

Batch scripts are just hopelessly broken. It really feels like we're abusing the hell out of them to do things they were never intended to do. The language is closer to Malbolge than C.

PowerShell is a whole other can of worms. I don't care for it either, but that'd be a separate discussion.

Bash on Windows sounded promising, up until "Windows 10 only" and "doesn't play nice with the regular Windows environment."

Re: How bad is the Windows command line really?

#56

Earlier quoted context omitted.

Have the line ending wars ended yet? Apple is finally Unix \n, but most internet protocols are \r\n as are Windows. Though honestly, Windows just doesn't even matter any more to me, I haven't needed to touch an MS product in years...

https://en.wikipedia.org/wiki/Newline#History \r\n, CR+LF historically speaking was the first, but \n, LF became dominant because of Unix.

If you break it down and view them as terminal codes (or as the spec was designed, on a teletype), CR+LF is correct, and LF is not.

However, the inconsistencies of this over time have become really annoying. My long term pet peeve is in VB.NET when I have to do this:

  ' This works - using the VB6 interop
  Split(StringName,vbCrLf)  
  
  ' This doesn't work - using the native .NET function
  ' because .split is only expecting a Char, and not a String)
  StringName.Split(vbCrLf)
Really, really annoying.

Re: How bad is the Windows command line really?

#57
post #55

It's really, really, really, really really bad. It doesn't even have a logical history. Despite having used it for many years, I still don't understand why when I type one command (eg make), and then another (eg out.exe), I have to toggle between pressing up or pressing down from the new command-prompt to access the previous commands. I can't make the window more than 80-characters wide dynamically. (I don't want to…

I agree it's pretty bad. But...

> I can't make the window more than 80-characters wide dynamically.

Windows 10 fixes this. You can resize the window and it wraps text better than any other terminal out there.

> Copy-and-paste as well is just complete garbage that takes forever.

Turn on Quick Edit. Now drag to select and right click to copy.

> There's no tab-completion.

Tab completion for filepaths works quite well for me.

Re: How bad is the Windows command line really?

#58
post #21

Earlier quoted context omitted.

But bash was around in the 80's, too, right? And it didn't seem to need those features. How did bash users get around your claimed need for this?

Bash first came out in 1989, but the typical shell of the time was sh, and it ran on Unix systems with more memory, storage, and CPU power than the typical PC. Thus it's no surprise that the sh family started with more features, while COMMAND which cmd evolved from was extremely minimalistic. DOS 1.0's COMMAND.COM was just slightly more than 3 kilobytes and didn't have conditional nor goto statements: http://www.os2m…

Even if the *nix machine was no bigger than a PC (e.g. - Xenix on '286; BSD on a PDP-11), it could still swap out processes, vs sharing a single real memory space.

But as you said, this allowed (at least the illusion, on some machines) more total memory to work with.

Re: How bad is the Windows command line really?

#59
post #29
post #2

Unreadable on mobile

Great, dowvoted for reporting a problem. Typical HN.

Right, because HN is the customer service department for the site hosting the article that somebody submitted a link to. And because "unreadable on mobile" is such an informative statement that contains so much useful data about why it was hard to read and what it was hard to read on. Surely you weren't downvoted for those reasons. Nah, it's just HN being HN.

Re: How bad is the Windows command line really?

#60
post #21

Earlier quoted context omitted.

But bash was around in the 80's, too, right? And it didn't seem to need those features. How did bash users get around your claimed need for this?

bash came out in 1989. The Bourne shell it's backwards compatible with is from 1977. But both were designed to run on Unix on multi-user multi-process machines. DOS batch language was designed to run on a single-user single-process machine. There's a reason they used to make a distinction between "minicomputers" and "microcomputers".

> DOS batch language was designed to run on a single-user single-process machine.

This. My preferred explanation for the difference between Unix and Windows for a long time has been "Unix assumes a lot of people are doing different things on one computer, all at the same time. Windows was designed with the mental model of a calculator."

Post reply on HN