That's not really true, you can serialize as json in all of those
HN user
Jayku1
They fixed this in later versions with the literal: --%
But you can also always use start-process like:
start-process app @'
your arguments and parameters go here
'@
This is a really strange argument -- he's saying that PowerShell was designed so that you could more easily move from shell to script to library ...
Your counter is -- you don't do that? Of course you don't, because your shell is bash. That's exactly the point. If your shell is bash, when you write a script you use a different language. What if there was a shell where you could actually script ...
You're absolutely right, PowerShell is made for both, and it has made compromises (like using comparison operators like -eq instead of ==).
Compromises are not inherently bad.
Ah, that's beautiful. Using a true-Scotsman argument to claim it's not "Real" open source, while denigrating Microsoft for NIH. Classic.
ConvertTo-CSV converts each property into a single string. Rich object? Tough. You get a string. If the type does not support a nice string representation, you get type names, like "System.Collections.Generic.List`1[System.String]" in your CSV output.
ConvertTo-Json serializes in-depth ... properties that are actually rich objects become nested dictionaries instead of simple strings. For instance, the "Parent" which is a Folder object. Recursively, up to the depth allowed.
Anyway, when you convert back, you don't get actual FileInfo and DirectoryInfo objects, you get dynamic property bags. So those complex properties remain dictionaries ... which ConvertTo-CSV turns into strings in a very different way.
If you specify -Depth 1 when you ConvertTo-Json ... the resulting output would be very similar.
WinRM and PowerShell Remoting do not use Kernel Mode Caching, and are therefore not vulnerable.
If Chrome uses "whatever encrypted storage the system provides" why aren't the credentials stored in the OSX keychain or the Windows Credential Manager, where the user has to re-enter their login password to see them...
I think the data in question is more likely to be feature usage statistics of the sort that show that when a browser does has a master password option, something less than 2% of users set it, and half of those unset it after they realize they're going to be prompted for it over and over and over all day.
Are you on XP with IE6 or something? IE uses the Windows credential store nowadays, which requires you to reenter your logon password before it will expose your password....