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 ==).
> If your shell is bash, when you write a script you use a different language.
The number of bash scripts I see for various -n-x related tasks suggests that this is substantially untrue; people do, in fact, do scripts in bash.
> What if there was a shell where you could actually script ...
I can't think of any shell that you can't script. OTOH, interactive use and scripting are substantially different use cases, so it really makes sense to have both interactive-optimized languages that may be usable in script and scripting languages that may be usable interactively, but focus use of each in their optimized role.
> Your counter is -- you don't do that? Of course you don't, because your shell is bash.
Yeah of course I'd use Bash because Powershell only just became available for other platforms, but that's not my point.
I understood his point like this: the grandparent of his post said powershell has some bad things for scripting. Someone responded to that by saying it's not just for scripting. He said something which I understand as 'that's not quite right, I see a command as a stepping stone to writing a script', To which I finally responded 'I enter a lot of commands but rarely write scripts in [my interpreter of choice's language] because that language just isn't that great, and that's fine because the language is great for its purpose: command line usage'.
And compromises are inherently bad (in a way), that's the definition of a compromise: there are two or more mutually exclusive options and different parties have different first choices. Since they're mutually exclusive, a compromise must be made which is acceptable for both, but it's the first choice of neither (or at most one of them). Compromises are necessary for a dual-use language, but they don't make it prettier for both usages either.
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.
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....
