4 ms·

It is a thoughtfully crafted product regarding what "command-line interface" should look like. How so? I've never appreciated what's actually good about p

It is a thoughtfully crafted product regarding what "command-line interface" should look like. How so? I've never appreciated what's actually good about powershell... you pass objects around? So...? Is that a thing that's useful? If you want to just automate a task, having intermediate objects that are serializable (eg. strings) so you can `foo ... > blah` and inspect the value of blah before continuing (`cat blah | command2...`) has always seemed far more tangibly useful. Having methods on an object you can invoke like a REPL for the OS sounds like a good idea, but I've never actually found it useful; its like the python REPL; useful for prototyping and doing stuff after you've imported the 50 packages and setup all of the environment, but once you open a new instance, you've got to spend the time doing that before you can actually do any work; and its useless for scripting. ...but, powershell gets a lot of love from people; so what do you actually find it useful for? Honestly curious, I've only ever touched it briefly and then swapped over to other things.

HelloNurse 10y ago
I'm using a large corpus of Powershell scripts, mostly written by enthusiastic Microsoft consultants, and even if I know exactly what they do I cannot stand the mysterious imports, the sequences of script invocations and bare statements that leave the session with the desired invisible state (and, conversely, closing and reopening the session after every major command just in case), the automagical option handling, and so on.
- Karrot_Kream 10y ago
  To play devil's advocate, UNIX sh shell scripts are pretty mysterious too, and often leave the local environment polluted and other such no-nos.
  - HelloNurse 10y ago
    Environment variables (and files) are very easy to inspect and change, the invisible bunch of objects in a Powershell session are not.
- btschaegg 10y ago
  That's my impression, too. It offers a really nice feature set and surely is the one piece of windows you can get the most done with out of the box. But boy is it ugly. And the worst thing is that all the really nice functionality .NET provides with LINQ is implemented halfway at best, if at all...
MaulingMonkey 10y ago
> If you want to just automate a task, having intermediate objects that are serializable (eg. strings) so you can `foo ... > blah` and inspect the value of blah before continuing (`cat blah | command2...`) has always seemed far more tangibly useful. String parsing is the bane of my command line scripting experience. Even in targeting "identical" environments, all it takes is one changed installation default altering the output of one of my many commands for my scripts to break - usually in some non-obvious ways that require a good hour to get to the bottom of, rework, and fix. To prevent such changes from forcing me to rewrite my entire scripts every time, I try to centralize such text parsing and munging in one place, "deserializing" those strings once and feeding it to the rest of the system. Shipping around this deserialized state in command line scripting languages can be so awkward at times, as to warrant rewriting the entire thing in a proper programming language. Inter-operating between your new program and your existing scripts will, of course, require even more text parsing. Don't get me wrong, sometimes munging text is your least horrible option. Powershell still lets you do that. But Powershell's objects also let you, with great frequency, skip the "try to 'deserialize' text that was really formatted for humans and isn't versioned, can be ambiguous, and otherwise was never written with machine consumption in mind" step. If I feel the need for a 'proper' programming language for parts of my script, I can write C# modules and use them from powershell without writing a bunch of text (de)serialization code on either end. This singlehandedly eliminates entire swaths of the most brittle, opaque, and otherwise obnoxious code to ever grace my scripts. TL;DR: Strings shot my dog.
- jamescostian 10y ago
  I've been using shells on Linux VMs and Macs for years now and I've probably written less than 50 functions, and the number of times I've typed sed or awk is probably lower than 100. I pull out the real scripting languages for real jobs. I only use shells for quick things. Sure, I could write a Python script right now that would read me the last lines of a log file on a remote server. Or, I could just type something like this and hit enter: ssh user@server "tail /path/to/log" I think what GP is trying to say is that PS is in an awkward position between the two. It has a deeper understanding than bash/zsh/whatever, but it also requires more typing. Yes, PS will fix issues like the ones you have described, but typing in long names (at least for me) defeats the purpose of using a shell in the first place. I don't want to type in "Get-Item" or whatever a million times, nor do I want to ever worry that using redirection (e.g. "something > log.txt") will mess up because PS defaults are the way they are.
Corrado 10y ago
I've been using PS for quite a bit of AWS automation lately and I have to say that I don't like it. Sure, you can pass objects around, but I've happened upon more than one cmdlet that does the wrong thing with the incoming object. In one case I was passing a "String" object to a cmdlet that accepts strings and it didn't know what to do with the object so it generated a fairly obtuse error. I had to manually cast the String object to a string. Grrr... Another thing that bothers me is the lack of single line composability. In most Unix shells you can pipe things around with abandon; it's not pretty but it works. One more than one occasion, while working with PS, I've had to create a cmdlet because there is no way (or I don't know how) to store intermediate values between cmdlets. One example was processing things in a loop. I had to store the current value in a variable and then process that variable in another line. I know someone here will give a solution, but I looked for an hour before giving up and creating a script file. On top of everything else, the cmdlets from Microsoft have differing switches for the same thing. One command might use -ServerName while another command will use -ComputerName. So, basically, you end up looking everything up before you can use it. I know Bash isn't much better, but at least I can expect that the tools are separate and not really designed to work together. I was expecting more consistency from PowerShell.
danudey 10y ago
My (likely uneducated) view of PowerShell: 1. It's amazing because Windows-only admins (or predominantly Windows admins with almost no Linux experience) have never seen anything like it before. Until PowerShell, the state of the art was VB scripting or batch files, both of which are (objectively) garbage. Regardless of how long the rest of us have been working with shell scripts, Python scripting, etc., Windows users have never had the opportunity to do similar things with similar tools which are included with the OS. 2. It's amazing because it does a lot of great things that even bash scripting can't do. The idea of passing around structured data can be super handy for a lot of common topics. For example, on Linux I have to use 'ip addr list' to get list of IPs, grep to get just the IPs, awk to get just the IPs, and now I have a list of IP addresses. It's a huge stupid hassle that I have to do every single time I want to write a script that takes advantage of IP addresses. Making everything a string makes sense when it's 1970 and you want everything to be compatible, but when basically none of the tools I use on a day-to-day basis provide the option for easily machine-parse-able output, it ends up very frustrating. The (theoretical?) promise of Powershell is that all output is machine-parse-able. The benefit of passing objects around is that you could do things like Get me a list of network interfaces | filter by interfaces which are up | which have IP addresses | just show me the IP addresses. The few examples I've seen make it feel like your shell is some sort of half-bash/half-SQL system where you can filter, process, and loop over objects. I can't count how many shell scripts I've had to write which parse output to get the list of data I want, then go back over that same output again to do actual work on it. You can hack a lot of stuff together with ugly hacks; getting all the interfaces on a MacOS machine with IPs except loopback? Maybe 'ifconfig | egrep "^[a-z]|inet[^6]" | grep -B1 'inet' | grep '^[a-z]' | grep -v lo' would do it. In most cases. Probably there's a better way to do it, but if you just want to get something written then you can hack it in like this, or loop over 'ifconfig -lu' (which, on my machine, shows 13 'up' network interfaces), etc.

HelloNurse 10y ago

I'm using a large corpus of Powershell scripts, mostly written by enthusiastic Microsoft consultants, and even if I know exactly what they do I cannot stand the mysterious imports, the sequences of script invocations and bare statements that leave the session with the desired invisible state (and, conversely, closing and reopening the session after every major command just in case), the automagical option handling, and so on.

Karrot_Kream 10y ago
To play devil's advocate, UNIX sh shell scripts are pretty mysterious too, and often leave the local environment polluted and other such no-nos.
- HelloNurse 10y ago
  Environment variables (and files) are very easy to inspect and change, the invisible bunch of objects in a Powershell session are not.
btschaegg 10y ago
That's my impression, too. It offers a really nice feature set and surely is the one piece of windows you can get the most done with out of the box. But boy is it ugly. And the worst thing is that all the really nice functionality .NET provides with LINQ is implemented halfway at best, if at all...

MaulingMonkey 10y ago

> If you want to just automate a task, having intermediate objects that are serializable (eg. strings) so you can `foo ... > blah` and inspect the value of blah before continuing (`cat blah | command2...`) has always seemed far more tangibly useful. String parsing is the bane of my command line scripting experience. Even in targeting "identical" environments, all it takes is one changed installation default altering the output of one of my many commands for my scripts to break - usually in some non-obvious ways that require a good hour to get to the bottom of, rework, and fix. To prevent such changes from forcing me to rewrite my entire scripts every time, I try to centralize such text parsing and munging in one place, "deserializing" those strings once and feeding it to the rest of the system. Shipping around this deserialized state in command line scripting languages can be so awkward at times, as to warrant rewriting the entire thing in a proper programming language. Inter-operating between your new program and your existing scripts will, of course, require even more text parsing. Don't get me wrong, sometimes munging text is your least horrible option. Powershell still lets you do that. But Powershell's objects also let you, with great frequency, skip the "try to 'deserialize' text that was really formatted for humans and isn't versioned, can be ambiguous, and otherwise was never written with machine consumption in mind" step. If I feel the need for a 'proper' programming language for parts of my script, I can write C# modules and use them from powershell without writing a bunch of text (de)serialization code on either end. This singlehandedly eliminates entire swaths of the most brittle, opaque, and otherwise obnoxious code to ever grace my scripts. TL;DR: Strings shot my dog.

jamescostian 10y ago
I've been using shells on Linux VMs and Macs for years now and I've probably written less than 50 functions, and the number of times I've typed sed or awk is probably lower than 100. I pull out the real scripting languages for real jobs. I only use shells for quick things. Sure, I could write a Python script right now that would read me the last lines of a log file on a remote server. Or, I could just type something like this and hit enter: ssh user@server "tail /path/to/log" I think what GP is trying to say is that PS is in an awkward position between the two. It has a deeper understanding than bash/zsh/whatever, but it also requires more typing. Yes, PS will fix issues like the ones you have described, but typing in long names (at least for me) defeats the purpose of using a shell in the first place. I don't want to type in "Get-Item" or whatever a million times, nor do I want to ever worry that using redirection (e.g. "something > log.txt") will mess up because PS defaults are the way they are.

Corrado 10y ago

I've been using PS for quite a bit of AWS automation lately and I have to say that I don't like it. Sure, you can pass objects around, but I've happened upon more than one cmdlet that does the wrong thing with the incoming object. In one case I was passing a "String" object to a cmdlet that accepts strings and it didn't know what to do with the object so it generated a fairly obtuse error. I had to manually cast the String object to a string. Grrr... Another thing that bothers me is the lack of single line composability. In most Unix shells you can pipe things around with abandon; it's not pretty but it works. One more than one occasion, while working with PS, I've had to create a cmdlet because there is no way (or I don't know how) to store intermediate values between cmdlets. One example was processing things in a loop. I had to store the current value in a variable and then process that variable in another line. I know someone here will give a solution, but I looked for an hour before giving up and creating a script file. On top of everything else, the cmdlets from Microsoft have differing switches for the same thing. One command might use -ServerName while another command will use -ComputerName. So, basically, you end up looking everything up before you can use it. I know Bash isn't much better, but at least I can expect that the tools are separate and not really designed to work together. I was expecting more consistency from PowerShell.

danudey 10y ago

My (likely uneducated) view of PowerShell: 1. It's amazing because Windows-only admins (or predominantly Windows admins with almost no Linux experience) have never seen anything like it before. Until PowerShell, the state of the art was VB scripting or batch files, both of which are (objectively) garbage. Regardless of how long the rest of us have been working with shell scripts, Python scripting, etc., Windows users have never had the opportunity to do similar things with similar tools which are included with the OS. 2. It's amazing because it does a lot of great things that even bash scripting can't do. The idea of passing around structured data can be super handy for a lot of common topics. For example, on Linux I have to use 'ip addr list' to get list of IPs, grep to get just the IPs, awk to get just the IPs, and now I have a list of IP addresses. It's a huge stupid hassle that I have to do every single time I want to write a script that takes advantage of IP addresses. Making everything a string makes sense when it's 1970 and you want everything to be compatible, but when basically none of the tools I use on a day-to-day basis provide the option for easily machine-parse-able output, it ends up very frustrating. The (theoretical?) promise of Powershell is that all output is machine-parse-able. The benefit of passing objects around is that you could do things like Get me a list of network interfaces | filter by interfaces which are up | which have IP addresses | just show me the IP addresses. The few examples I've seen make it feel like your shell is some sort of half-bash/half-SQL system where you can filter, process, and loop over objects. I can't count how many shell scripts I've had to write which parse output to get the list of data I want, then go back over that same output again to do actual work on it. You can hack a lot of stuff together with ugly hacks; getting all the interfaces on a MacOS machine with IPs except loopback? Maybe 'ifconfig | egrep "^[a-z]|inet[^6]" | grep -B1 'inet' | grep '^[a-z]' | grep -v lo' would do it. In most cases. Probably there's a better way to do it, but if you just want to get something written then you can hack it in like this, or loop over 'ifconfig -lu' (which, on my machine, shows 13 'up' network interfaces), etc.