Live data from Hacker News

A Saner Windows Command Line

futurice.com

131–140 of 164 posts

Re: A Saner Windows Command Line

#132
post #105

Earlier quoted context omitted.

What's the bash equivalent of something like this? Get-Command -Module SQLPS | ?{$_.Parameters.Values.ParameterType -contains [PSCredential]} In PowerShell, this means "show me all the commands from the SQLPS module that take a credential object as one of the parameters".

This question weighs to powershell's side, and I wouldn't call it fair (and not just because I don't know powershell), but I'll bite. Print all files in package: `dpkg -L ` (for Debian based OSes) Filter executable commands: ` | grep 'bin/.'` (assuming the package adheres to standards) Check parameters of command: ` --help` (again, assuming the developers have adhered to convention) Of course, if one needs to check m…

"Which commands from XYZ package require credentials?" hardly seems unfair.

Your suggestion solutions illustrate the point well - you have to memorize some convention of where utils are located, how they display usage info, then cross your fingers and hope developers have followed it. And it's not even complete, since I'm guessing there is no solid convention for parsing a manpage to find which args represent credentials.

In powershell, cmdlets and their args are typed, so you just ask for all cmdlets that have an arg with the credential type. Everything above is tab-completable, too, and thus discoverable at least to some level.

Re: A Saner Windows Command Line

#133

To hear bash-people to call Powershell "non-intuitive" sounds like those immigrants that go to a foreign land, refuse to learn the local language and insist on the natives to understand their immigrant language. Or like programmers that think that every programming language should have the C syntax. Bash and Unix commands are only "intuitive" after years of practice; Powershell is not different. And it doesn't have a…

I am a big fan of Powershell, yet...and there had to be a "yet", now didn't there?...the Bash based criticism is well grounded even if not always perfectly articulated.

I see it this way, the great thing about Powershell commands is that I get back an object. The great thing about Bash commands is that I get back text. The object is great because I don't have to parse it. The text is great because I can parse it.

The downside of Powershell is that if I don't have technical expertise in regard to the object a command returns, I have to go read deep into a manual to figure how I can do something simple. The downside of Bash is that if I have deep technical expertise about the text that is returned, I still have to parse it as text to do something simple.

The high level abstractions of Powershell are better suited for dealing with known processes and contexts where I care about the semantics of the returned value. The low level abstraction of text is better for dealing with unknown processes and contexts where I don't really care about the semantics of the value.

Re: A Saner Windows Command Line

#135

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

let me guess (the keyboard is the give away) when you say unix, you mean osx. Yeah, that terminal induces rage, and the bash is like 40 years stale.

Re: A Saner Windows Command Line

#136
post #51

No mention of clink ? surprising, cmd.exe meets readline. Highest ROI 'update' I know on Windows https://mridgers.github.io/clink/

ConEmu plus clink is my mitigation of choice. Line oriented copy/paste, instead of cell oriented, is a big win.

In Win10 there is finally line-based copy/paste built-in. You can still get block-based by holding Alt.

Re: A Saner Windows Command Line

#137
post #105

Earlier quoted context omitted.

What's the bash equivalent of something like this? Get-Command -Module SQLPS | ?{$_.Parameters.Values.ParameterType -contains [PSCredential]} In PowerShell, this means "show me all the commands from the SQLPS module that take a credential object as one of the parameters".

This question weighs to powershell's side, and I wouldn't call it fair (and not just because I don't know powershell), but I'll bite. Print all files in package: `dpkg -L ` (for Debian based OSes) Filter executable commands: ` | grep 'bin/.'` (assuming the package adheres to standards) Check parameters of command: ` --help` (again, assuming the developers have adhered to convention) Of course, if one needs to check m…

But can't you see that's bad?

1. It doesn't work on all distros, and even on Debian you need to already know that "dpkg -L" gets a list of commands. I tried googling "debian distro package tool" and it doesn't tell me about dpkg. Discoverability.

2. The reason you're praying that the package developer put everything in 'bin' is because there's no metadata to distinguish between commands and other files.

3. You're actually executing(!!) the commands to get the help, because, again, no metadata. Parsing the arguments is delegated to the command, so what if the command ignores the --help and reboots your server instead? (Note that if you run a PowerShell cmdlet with -?, it doesn't actually hand control over to the command.)

4. At the end of the day it's not going to work because all of the parameters are strings and all you can look for is the parameter name, which might be "password" or "pass" or "pwd" or anything else the author picked. (Another reason this matters is the PSCredential is stongly-typed and backed by a SecureString, so if the process crashes it won't get leaked into the heap dump. In your Linux command it's just a plain-text string on the heap.)

Now, I'm not trying to say you should give up bash/Linux and become a Windows fan boy. I'm saying you need to take an honest look at bash and decide whether it makes sense to stick with that paradigm in the 21st century.

Re: A Saner Windows Command Line

#138

To hear bash-people to call Powershell "non-intuitive" sounds like those immigrants that go to a foreign land, refuse to learn the local language and insist on the natives to understand their immigrant language. Or like programmers that think that every programming language should have the C syntax. Bash and Unix commands are only "intuitive" after years of practice; Powershell is not different. And it doesn't have a…

I've just recently gone back to using Windows 10 after being a heavy XP user. I think Powershell is perfectly fine... for my uses up to now there's always a tutorial online to help. And some commands are the same between shells so I wasn't completely lost :/

Re: A Saner Windows Command Line

#139
post #80

Earlier quoted context omitted.

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

Unix command line autocomplete is fairly good, but it's not useful for discovery of new features or for helping you figure out a CLI without reading anything. It is quite effective at helping a user who knows what they're avoid keystrokes, though.

Bash completion is inferior. It doesn't understand types.

Re: A Saner Windows Command Line

#140

Earlier quoted context omitted.

> 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?

PowerShell v3+ can autocomplete command names, command switches and switch values (if they're a strict set). It can also autocomplete object properties yes.

    $dir = gci
    $dir. -> $dir.Count
Post reply on HN