3 ms·
I found -- when I last did anything in Powershell years ago -- that third point of yours to be incredibly frustrating. I wanted to iterate over a list, but som
by at_a_remove 4y ago
I found -- when I last did anything in Powershell years ago -- that third point of yours to be incredibly frustrating. I wanted to iterate over a list, but sometimes I would get back a non-iterable solo object, or a None-like object, and my iteration would fail.
I ended up doing a lot of testing to see what my returned results were.
- jasomill 4y agoAs with any large software project, there are at least few features in PowerShell that are confusing, inconsistent, or both. Auto-vectorization is one of them; usually it "just works", but can be a PITA when dealing with, e.g., pipelines returning sequences you'd prefer to keep separate. Another is that PowerShell error handling, while robust and powerful, can be difficult to implement properly, especially when "the right thing" isn't what PowerShell expects. Case in point: originally, PowerShell handled standard error output from external commands specially, wrapping lines of stderr output in error objects. While convenient in some cases, this made it unnecessarily difficult to work with external commands that output to stderr in non-failure cases, and was therefore changed in newer versions of PowerShell. A final, non-language example is cmdlet availability on non-Server Windows versions. While PowerShell mostly has feature parity between desktop and server SKUs, there are at least a few non-Server-specific cmdlets that only work with Windows Server. The only example that comes immediately to mind is the ...-WindowsFeature set of cmdlets to manage installed Windows features; while present on client Windows systems, they fail with an error message unless the target system is running Windows Server. This is a particularly mystifying omission because dism.exe provides an equivalent command-line interface that works everywhere.