Get-CobolFingers -Variant=Microsoft -Payoff=MuchLessThanAdvertised
PowerShell is open sourced and is available on Linux
591–600 of 790 posts
Re: PowerShell is open sourced and is available on Linux
#592Earlier quoted context omitted.
I feel very similarly, but then I'm of the mind that if I can't apt-get it, I'm not interested, and I'll bet that "open source" doesn't mean to MS what it means to the open source world. As for the NIH syndrome, one of my favorite Paul Graham essays is still "What Languages Fix" ( http://www.paulgraham.com/fix.html ) particularly for C#: the problem that C# was invented to solve is that Microsoft doesn't control Java…
except that C# as a language is by leaps and bounds better than Java (both in syntax and useful features departments), so there have been other problems to solve, too.
In JVM land, now Java just hands you some specific well tested libraries: You write business code with Scala or Clojure, which I'd pick over C# by about as much as I'd pick C# over Java 7.
That said, I have far more faith in Microsoft improving their tooling than I have about Oracle doing the same: It's just that Oracle has to carry a far smaller weight, because the good JVM languages aren't even theirs.
Re: PowerShell is open sourced and is available on Linux
#593Earlier quoted context omitted.
I'm not entirely convinced that "plain text" is "simple." For one, utf-8 is a variable-length encoding, which can cause all sorts of subtle bugs and sometimes leads to security issues because somebody failed to parse a character correctly somewhere. On top of this, using plain text means that every program has to choose its own control characters, essentially an encoding within an encoding. This is great for readabil…
For one, utf-8 is a variable-length encoding, which can cause all sorts of subtle bugs and sometimes leads to security issues because somebody failed to parse a character correctly somewhere. UTF-8 is nice in that extended characters, despite consisting of multiple bytes, will never contain a low-ASCII character amongst them. Unless you're dealing with byte offsets, splitting and scanning UTF-8 strings by delimiters…
Re: PowerShell is open sourced and is available on Linux
#594Earlier quoted context omitted.
[Disclaimer: I work for Microsoft.] As far as I recall, the original impetus behind what became PowerShell (as handed down to us in a conference room by Ballmer himself, sometime around 2001) was to fill the gap between ops people who did enterprise administration manually with tools like MMC and engineers who automated enterprise administration with tools like C++/DCOM. The latter were necessary in a lot of cases, b…
I was part of the Hotmail team which consisted mainly of Solaris admins trying to mass administer a giant number of Windows servers. We kept pleading with the Windows team and upper management (forgot who it was at the time, Raikes?) to give us a powerful shell and ssh on Windows. We ended up licensing FSecure's ssh daemon for windows. We also used cygwin, too.
It was Allchin when I was there... about that era.
Re: PowerShell is open sourced and is available on Linux
#595Earlier quoted context omitted.
I never said anything about not liking command line tools. In fact I love them and think they do a awesome job! In any case you just proved my point. You think its insane to parse binary data while scripting and I do too. That is why I think the passing binary objects is insane on the shell. Now if you were talking about text base objects (not binary ones) then that is an entirely different story and I feel that is w…
This isn't about binary vs text, it is about structured vs. unstructured. The legacy of UNIX is flat text. Yes it may be expressing some underlying structure, but you can't access that structure unless you write a parser. Writing that parser is error-prone and unnecessary cognitive burden. PowerShell makes it so the structure of objects is automatically propagated between processes. This is undeniably an improvement.…
Other programs that expect to be machine parsable define in great detail the output. In your initial post I replied to you mentioned ps. In the case of ps it has many options to help you get the data you want without using standard parsing tools. That is because its output was expected to be consumed by both humans and possibility other programs.
Now take readelf on the other hand. It clearly talks about in its man page about being more readable. Its author cares about how it will look on a terminal and even goes through the effort to implement -W which makes it nice to view on larger terminals. It even shows in print_vma, where somebody wen tout of their way to print hex if the number was larger than 99999. If the author really cared about the ability to be parsed they would have added a OUTPUT FORMAT CONTROL section that would provide you the contract you are looking for. Just saying if the data was in JSON does not solve your problem. Why? Because the author of readelf did not spend time to define its output properly in the man page it is not likely he/she would have implemented a json output type when piped little alone take the time to provide the object structures in the man page.
You say it's not about binary vs text but I don't think that can be said. There are lots of things to consider.
* Speed of encoding and decoding. * Memory consumption issues with larger objects needing to be fully decoded before being able to be used or processed. * Binary data would need to be encoded and would likely result in much more overhead.
Its not clear to me that a binary option would not be better than a text one. Pipes today are not just used for simple scripts and system management.
There are lots of things that concern me, maybe it is just the implementation details.
* Not all command line programs are written with the expectation to be parsed. How do we handle that? Force the programmer to make all output parsable regardless if they ever intended on the program being used in some script? * Would a program put the same thing to stdout even if it was flowing to a terminal? Are terminals not for humans? * Would structure be enforced? One of the awesome things about stdin/stdout is that you can send ANY data you want.
That all said I would love it if programs who intended on their output to be parsed offered a JSON output. I am not against structured output. I am against forcing programmers to shoehorn their output into some format that may not be the best for their program. I think a well designed and documented command line tool that expects to be parsed by other programs will go out of its way to ensure the format is documented and adhered to when operating.
Re: PowerShell is open sourced and is available on Linux
#596Earlier quoted context omitted.
For one, utf-8 is a variable-length encoding, which can cause all sorts of subtle bugs and sometimes leads to security issues because somebody failed to parse a character correctly somewhere. UTF-8 is nice in that extended characters, despite consisting of multiple bytes, will never contain a low-ASCII character amongst them. Unless you're dealing with byte offsets, splitting and scanning UTF-8 strings by delimiters…
Is there no trivial way to print a PowerShell object? As JSON or XML or an ascii table formatted into columns? That seems like a point of friction, then, I'd agree.
(australis) ~\Desktop % Get-ItemProperty e
Directory: C:\Users\Dustin\Desktop
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 8/12/2016 9:06 AM e
I believe types can specify which columns to display by default; if you want more info, there's always `Format-List`: (australis) ~\Desktop % Get-ItemProperty e | format-list
Directory: C:\Users\Dustin\Desktop
Name : e
CreationTime : 8/11/2016 10:58:56 PM
LastWriteTime : 8/12/2016 9:06:13 AM
LastAccessTime : 8/12/2016 9:06:13 AM
Mode : d-----
LinkType :
Target : {}
It's also possible to format any object via `ConvertTo-JSON`: (australis) ~\Desktop % Get-ItemProperty e | ConvertTo-JSON
{
"Name": "e",
"Parent": {
"Name": "Desktop",
"Parent": {
"Name": "Dustin",
"Parent": "Users",
"Exists": true,
"Root": "C:\\",
"FullName": "C:\\Users\\Dustin",
"Extension": "",
...Re: PowerShell is open sourced and is available on Linux
#597Earlier quoted context omitted.
For one, utf-8 is a variable-length encoding, which can cause all sorts of subtle bugs and sometimes leads to security issues because somebody failed to parse a character correctly somewhere. UTF-8 is nice in that extended characters, despite consisting of multiple bytes, will never contain a low-ASCII character amongst them. Unless you're dealing with byte offsets, splitting and scanning UTF-8 strings by delimiters…
Is there no trivial way to print a PowerShell object? As JSON or XML or an ascii table formatted into columns? That seems like a point of friction, then, I'd agree.
http://windowsitpro.com/powershell/powershell-objects-and-ou...
It could be said that, in some ways, unstructured streams are far more WYSIWYG, which can conceptually mean easier understanding and use.
Re: PowerShell is open sourced and is available on Linux
#598Re: PowerShell is open sourced and is available on Linux
#599Microsoft is projecting that the .NET ecosystem will become a main revenue driver, regardless of the underlying operating system.
Which is why I have no doubt the Universal Windows Platform will become the Universal Platform and be a true desktop/tablet/mobile/server/etc Java competitor on all major OS (mobile, traditional and server). It must be rather frustrating for Microsoft to look back a decade or more and see they were sitting on the exact technology a hell of a lot of people said would be their future had they made it cross-platform fro…
Re: PowerShell is open sourced and is available on Linux
#600Earlier quoted context omitted.
Is there no trivial way to print a PowerShell object? As JSON or XML or an ascii table formatted into columns? That seems like a point of friction, then, I'd agree.
You can certainly print them, but there's no guarantee you'll get all its contents by default, and there's still the problem of how to create those objects from some other output, e.g. in a file. http://windowsitpro.com/powershell/powershell-objects-and-ou... It could be said that, in some ways, unstructured streams are far more WYSIWYG, which can conceptually mean easier understanding and use.