Live data from Hacker News

PowerShell is open sourced and is available on Linux

azure.microsoft.com

591–600 of 790 posts

Re: PowerShell is open sourced and is available on Linux

#592
post #242

Earlier 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.

Sure, it beats Java, but the VM is worse for running other languages, and that's where .NET loses. F# tries to be nice, but reified generics are more of a limitation than help in that world.

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

#593

Earlier 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…

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.

Re: PowerShell is open sourced and is available on Linux

#594
post #454
post #232

Earlier 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.

>forgot who it was at the time, Raikes?

It was Allchin when I was there... about that era.

Re: PowerShell is open sourced and is available on Linux

#595

Earlier 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.…

If the data was in JSON it would promise a that it followed the JSON spec -- but its not, it follows its defined spec, which in the case of readelf is apparently undefined.

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

#596

Earlier 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.

By default, an object at the end of a pipeline will be printed to the screen in tabular format.

    (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

#597

Earlier 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.

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.

Re: PowerShell is open sourced and is available on Linux

#599
post #51
post #5

Microsoft 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…

IMO this is why Google is currently building a new universal OS from scratch. They know the power Microsoft can yield with this. It will take some time to catch on, but when it does, it's going to be so big.

Re: PowerShell is open sourced and is available on Linux

#600

Earlier 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.

Or it can mean a lot harder to understand and use. With types you get all of the metadata that you might not even have if it was plain text. In addition, every application chooses it's own serialization format. In the end, the only programs that compose well are those that work on text, not structured data (i.e. grep, awk, sed, etc...)
Post reply on HN