A couple of thoughts about my PowerShell debugging experience:
- Nothing resembling `set -e` / `setopt errexit`. There's `$ErrorActionPreference`, but only works for cmdlets. You need to check `$LastExitCode` yourself, every single time. Great.
- Nothing resembling a debug trap (I'm literally talking about the `debug` trap in bash and friends). So, to do the `$LastExitCode` check, you need to wrap every native command call in some sort of dispatcher. Great.
- Something resembling `set -x` / `setopt xtrace`: `Set-PSDebug -Trace 1`, except whenever you execute a cmdlet, the cmdlet is traced too, as if it's sourced in a *nix shell; so run `Expand-Archive`, get a million lines of irrelevant trace. Great.
It's not like the people who built PowerShell weren't aware of *nix shells. The WSL people even called WSL "Bash on Windows" initially — it's incredibly stupid by the way, and the Bash (it's just a fucking shell) = Linux = Unix is one of the common signals of the ignorance of large segments of web developers, "app" developers, and Windows-based developers. PowerShell people also bothered to alias many common *nix commands to their weird Camel-CaseWithOneHyphen cmdlets. But some of the good and basic ideas are lost on them.
The object-orientedness is magical for a shell language, but very often it's just way too magical. You run `ls` and get one type of output; you insert another command before it and suddenly it's printing another type of output. Do you want this kind of magic in your shell? I don't.
To summarize my impressions, you pitch PowerShell against classic *nix shells, it's more powerful (since *nix shells delegate the power, aka munipluxity, to other programs), but it's missing the simplicity, oh and some pretty basic features. You pitch PowerShell against Python or Perl, it's slightly better in terms of whipuptitude (since it's a shell) and has a rich standard library that is good at certain categories of tasks, but it's extremely limited and vastly less portable. In the end, it's just a somewhat awkward tool to interface with Windows and do what shells typically do in a clumsy way.
Speaking of interfacing with Windows, they decided to create another shell instead of fixing cmd, which created a disconnect where certain tasks are okay in one yet vastly more complex or borderline impossible in another, and it goes both ways, so you can't simply pick one and discard the other. Just great.
Mostly bad ideas, and even good ideas are executed poorly. Quintessential Microsoft I guess.
---
Oh and here's another thing: checking dynamic linkage is painful as hell. The closest thing to `ldd` or `otool` appears to be `dumpbin` from Visual Studio, and where is it?
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\bin\Hostx86\x86\dumpbin.exe
Try to use that from a regular shell. Xcode has deep bins too but at least it provides `xcrun`. With VS, you have to run "Developer Command Prompt for VS 2017" — oh, and it's goddamn cmd, not PowerShell. And try to do that in a script. Just great.
---
P.S. I'm not saying Bash doesn't have pain points. I script in Zsh for a reason.
Okay, after another series of attempts, I tracked down the issue: Travis' Windows image is missing `avicap32.dll`, which is part of Video for Windows (VfW), which is part of Desktop Experience. Travis' Windows image is Server Core (1803), which does not include (and cannot be extended with) Desktop Experience. See https://travis-ci.org/SNH48Live/KVM48/builds/458591820, https://api.travis-ci.org/v3/job/458591821/log.txt, https://travis-ci.community/t/1024.