Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Saner Windows Command Line

futurice.com

Post reply on HN
Print view View original

81–90 of 164 posts

Re: A Saner Windows Command Line

#81

Post by gpvos »

a3n wrote: post #55
gpvos wrote: post #19

I tried both ConEmu (twice) and Console2 in the past, but both were too unstable for regular use. If someone can convince me that the situation has markedly improved, I might try again, but I guess I'll just wait until we upgrade to Windows 10 at my workplace (which they say is any day now).

Happy ConEmu plus clink user for at least a year, I suspect more, but I don't keep track, I just move on.

Hmm, just installed clink 0.4.7 (with autorun disabled for now). "clink autorun --help" consistently crashes. But at least it hasn't taken down the console yet, so I guess I'll try it out for some time. It's really a nice concept.

Re: A Saner Windows Command Line

#82

Post by dr_zoidberg »

13of40 wrote: post #66
simula67 wrote: post #38

Earlier quoted context omitted.

I guess the difference between bash scripting and powershell scripting is that you have to learn a lot of things upfront to be productive with Powershell. Bash, on the other hand, with its simpler syntax and collection of text based utilities you can get productive pretty quickly. If you want more power or if you want cleaner code you can always switch to Python et al. Thus, the learning curve is much more gentle. Th…

The first thing you should learn with PowerShell are the discoverability features: Tab completion, Get-help, get-command, show-command, get-member, get-alias. Last time I checked (and admittedly it's been a few years) bash has man pages and that's it.

I agree with you (was about to post something similar), and wanted to add that some unix commands (which become part of the soul of bash scripts), are sometimes named in weird, unintuitive ways. For one thing, one potentially dangerous command is simply called "dd", and its man page[0] says next to nothing at all about its true power, uses and danger.

[0] http://linux.die.net/man/1/dd

Re: A Saner Windows Command Line

#83

Post by pritambaral »

Aleman360 wrote: post #42
Touche wrote: post #20

Earlier quoted context omitted.

I think it's worth noting that powershell is .NET object-based. This means you can interact with powershell objects from a .NET language but not, for example, python. To me this is the fundamental flaw of PS. It's a neat idea as long as you stay within their box, within their ecosystem. With Bash you get a wealth of tools because everything can handle text.

> With Bash you get a wealth of tools because everything can handle text. And no autocomplete.

I didn't get this, could you elaborate? Does powershell autocomplete objects it is about to ingest, and before you run the command?

Re: A Saner Windows Command Line

#84

Post by bitwize »

CraigJPerry wrote: post #5

Powershell and its long winded cmdlets are really hard for me to like. I always fall back to cygwin on windows. I once wrote a PS script to set some power management options on a corporate laptop. The script was 11 lines long (vs 3 lines in Python), it was harder to read and understand. Even with ISE available it was much harder to write. I followed along with some exchange server tutorial where the prescribed easy w…

PowerShell obeys the first iron law of I/O: ALL data has a type. Bash (and Unix in general) -- does not.

Now of course the implementation of typed pipelines in PowerShell is clunky and forced, because typed I/O primitives do not (yet) actually exist in Windows, so all the piping is done within one process with streams of object pointers, else it doesn't work. There are other problems, too: I recall one advocate linking me to the PowerShit solution to some admin task like changing the ACLs of a directory tree recursively. It involved including a C# program as a herestring, passing it to the C# compiler, and loading the resulting bytecode. The advocate said "Isn't this beautiful and elegant?"

But in principle the model embraced by PowerShell is strictly more robust than bash's fragile "dumb byte pipes" model.

"Get a byte, get a byte, get a byte, byte, byte!" --NT architect Dave Cutler, on Unix I/O

Re: A Saner Windows Command Line

#85

Post by Touche »

dr_zoidberg wrote: post #78
Touche wrote: post #20

Earlier quoted context omitted.

I think it's worth noting that powershell is .NET object-based. This means you can interact with powershell objects from a .NET language but not, for example, python. To me this is the fundamental flaw of PS. It's a neat idea as long as you stay within their box, within their ecosystem. With Bash you get a wealth of tools because everything can handle text.

Googled "powershell ironpython" and got this[0] as first result. Before that, I was going to point out that IronPython, despite it's performance issues and nitpicky differences (there's no 'struct' module, but there's '_struct', which is... struct and they somehow forgot to rename) is still considered a .NET language. If there's anything wrong with the article (for one thing, it's 4 yo), please point it out. I just b…

You're missing my point.

Re: A Saner Windows Command Line

#86

Post by Touche »

13of40 wrote: post #72
Touche wrote: post #20

Earlier quoted context omitted.

I think it's worth noting that powershell is .NET object-based. This means you can interact with powershell objects from a .NET language but not, for example, python. To me this is the fundamental flaw of PS. It's a neat idea as long as you stay within their box, within their ecosystem. With Bash you get a wealth of tools because everything can handle text.

PowerShell objects are actually a superset of . Net objects. They can also represent COM objects, WMI objects, XML nodes, etc. You can also export them to CSV, XML, JSON, and yes, even text. If you have cygwin installed you can pipe to and from the cygwin commands from PowerShell and pipe to and from powershell.exe from your cygwin shell.

Languages are not the same, you'll never have interoperability; try exporting a .NET object with a 64-bit integer to be consumed by JavaScript, for example. Text wins.

Re: A Saner Windows Command Line

#87

Post by pritambaral »

13of40 wrote: post #66
simula67 wrote: post #38

Earlier quoted context omitted.

I guess the difference between bash scripting and powershell scripting is that you have to learn a lot of things upfront to be productive with Powershell. Bash, on the other hand, with its simpler syntax and collection of text based utilities you can get productive pretty quickly. If you want more power or if you want cleaner code you can always switch to Python et al. Thus, the learning curve is much more gentle. Th…

The first thing you should learn with PowerShell are the discoverability features: Tab completion, Get-help, get-command, show-command, get-member, get-alias. Last time I checked (and admittedly it's been a few years) bash has man pages and that's it.

Haven't used PS much – only used DuckDuckGo to find what each PS command meant, so it's possible I have misuderstood some, but – these are the bash alternatives, I think:

| :PowerShell | Bash: |

|Tab completion | built-in, OOTB|

|Get-help | `help`|

|get-command | `apropos -s .`|

|show-command | ` --help` or `man `|

|get-member | Inapplicable; text has a structure. Use `head -1` to find out, given structure is printed on first line |

|get-alias | `alias`|

Re: A Saner Windows Command Line

#88

Post by Karunamon »

dr_zoidberg wrote: post #82
13of40 wrote: post #66

Earlier quoted context omitted.

The first thing you should learn with PowerShell are the discoverability features: Tab completion, Get-help, get-command, show-command, get-member, get-alias. Last time I checked (and admittedly it's been a few years) bash has man pages and that's it.

I agree with you (was about to post something similar), and wanted to add that some unix commands (which become part of the soul of bash scripts), are sometimes named in weird, unintuitive ways. For one thing, one potentially dangerous command is simply called "dd", and its man page[0] says next to nothing at all about its true power, uses and danger. [0] http://linux.die.net/man/1/dd

I don't think it's dd itself that's dangerous, rather the fact that it's usage is often paired with root access to raw device nodes on the filesystem.

Even innocuous things like tee, cat, and bash output redirection can mess up your system if you blast something into /dev/sda.

Re: A Saner Windows Command Line

#89

Post by a3n »

gpvos wrote: post #81
a3n wrote: post #55

Earlier quoted context omitted.

Happy ConEmu plus clink user for at least a year, I suspect more, but I don't keep track, I just move on.

Hmm, just installed clink 0.4.7 (with autorun disabled for now). "clink autorun --help" consistently crashes. But at least it hasn't taken down the console yet, so I guess I'll try it out for some time. It's really a nice concept.

mmmrrrm, don't know, don't remember. I do know that when I start ConEmu, I have to ctrl-alt-J to get command line features. So maybe I had trouble with autorun too? Don't remember.

Re: A Saner Windows Command Line

#90

Post by marcosdumay »

rottyguy wrote: post #41

>> Let's be honest. What many people think of as "the default Windows command line", cmd.exe, is atrociously bad. Selection is awkward, resizing is hard, the syntax is arcane, the list goes on. If you do nothing else, there are two things you can do to make the basic, vanilla experience bearable. Funny, from a guy coming from Windows to Unix I think the exact opposite. Each command comes with a bazillion options and…

About the ^H, are you by any means telneting into a network server? That's the only way to get this problem that I know of on a modern Linux.

If so, use nc or ncat, telnet expects a terminal at the other end, something no system exports anymore. It's only there for interaction with ancient configurations.

Post reply on HN