3 ms·

Here's the thing about PowerShell: the community is not nearly as strong as bash/linux/unix. There's also been a substantial amount of churn between versions. T

Here's the thing about PowerShell: the community is not nearly as strong as bash/linux/unix. There's also been a substantial amount of churn between versions. These two things (combined with the insanity that is Technet) result in frequently less-than-helpful Google results when researching a particular problem. More often than not the first Stackoverflow result is either flat out wrong or non-idiomatic. It doesn't help that (as you mentioned) you can do straight .NET stuff in Powershell also, so even if there is a cleaner, native cmdlet available half the Google results for a given problem will be some weird .NET mashup. Also, Windows has it's own bizarre legacy command line tools ("net", "sc", etc.) which predate PS and further convolute any attempt to find the "right" solution to any given problem. In general, if you're using Windows 2012+, 95% of systems administration and programming tasks now have native Powershell cmdlets. There is very little need to dive into .NET or WMI crap anymore, thank God.

xorcist 12y ago
Yeah, I think what you call legacy command line tools are the biggest part of the problem, but the mere fact that there are new and old ways to do things _will_ be a problem in the future. In general, Windows tends to give you an API whereas UNIX historically is data centric. My experience is that I prefer the latter. Greatly. For example, to get change stuff in the AD environment at work, the local windowshead wants me to send the changeset in a home cooked format for his horrible PS muck to parse. Integration with configuration management systems is spotty at best, and if I in two years time need to revisit the change I have to pray that particular backend still exists. If I did it in UNIX I would just accept standard diff:s, keep data version controlled, and be done with it.

xorcist 12y ago

Yeah, I think what you call legacy command line tools are the biggest part of the problem, but the mere fact that there are new and old ways to do things _will_ be a problem in the future. In general, Windows tends to give you an API whereas UNIX historically is data centric. My experience is that I prefer the latter. Greatly. For example, to get change stuff in the AD environment at work, the local windowshead wants me to send the changeset in a home cooked format for his horrible PS muck to parse. Integration with configuration management systems is spotty at best, and if I in two years time need to revisit the change I have to pray that particular backend still exists. If I did it in UNIX I would just accept standard diff:s, keep data version controlled, and be done with it.