Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“It's easier to port a shell than a shell script” (1998)

gopher.quux.org

Post reply on HN
Print view View original

61–68 of 68 posts

Re: “It's easier to port a shell than a shell script” (1998)

#61

Post by useerup »

integraton wrote: post #48
MrQuincle wrote: post #28

Earlier quoted context omitted.

Can you explain me a bit the difference if you mind (I don't know much about Windows). In Linux/Unix I can also pipe audio to /dev/audio for example. And image processing through a sequence of steps by pipes is quite often done. Are these objects coming with default metaparameters to make piping easier? Or are there other things implemented that might be cool?

PowerShell's object pipeline only exists within the PowerShell/.NET runtime and is functionally analogous to method/function chaining in languages like JavaScript and Ruby. The object pipeline does not exist outside of the PowerShell/.NET runtime. Pipelines in Unix shells use OS-level functionality to connect standard streams of data, often encoded as text, between arbitrary executables written in any language. The r…

> which is function chaining within a single runtime

If PowerShells pipelines are merely equivalent to function chaining, then you should have no problem replicating the following very simple pipeline with function chaining in Ruby, Python or JavaScript:

    cat log.txt -wait | sls "error"
In case you need an explanation for what it is doing: It continously monitors the log.txt file for new lines, and selects those that contains the substring "error".

But I am curious: Why is it important whether the pipelines could be implemented using function chaining or not? PowerShell is a shell where I interact with the system through commands. Yes - those commands are not the typical Unix executables - but they act as commands within the shell

Is your problem that it is not a Unix shell? You could equally well say that Unix shell pipelines are just processes connected by file descriptors. That is factually correct but does not represent the true utility of pipelines.

PowerShell pipelines are not file descriptors. PowerShell commands do not execute in separate processes. But PowerShell commands are versatile and can be combined in a way analogous to Unix shell pipelines where the output of one command is consumed and acted upon by the next command.

The object of a operating system command line shell is to expose the operating system features to the user of the shell. Why does it matter whether it uses Unix file descriptors. Even if PowerShell pipelines were equivalent to "just" chained functions, why does it matter?

I get the point that you need the .NET runtime to run PowerShell, because it is implemented using .NET. At what point do we consider a runtime part of the operating system. When it is intrinsically distributed with the operating system and cannot be uninstalled?

Re: “It's easier to port a shell than a shell script” (1998)

#62

Post by useerup »

integraton wrote: post #60
useerup wrote: post #58

Earlier quoted context omitted.

> You are the same person who tried to falsely claim that cmdlets are not instances of .NET classes The fact stands, cmdlets can be implemented as .NET classes, but they can also be implemented through script (i.e. not .NET classes) or through manifests where cmdlets are generated for WMI/CIM classes. I don't know why you continue to ignore this, or even why it is important. I point out that you are incorrect and poi…

Your statements about cmdlets are simply false, and you are again trying to handwave past the fact that PowerShell is a .NET CLI and that its object pipeline only exists within its .NET runtime and is analogous to function chaining within a single runtime like in Python or Ruby, not Unix pipelines. From the Microsoft documentation, which I quoted to you in a previous discussion, so you should already know it (which w…

> Then those generated cmdlets must be instances of .NET classes, because by definition that's what cmdlets are

Nope. The problem is that you searched for confirmation that cmdlets was "just" .NET classes (I really don't get why that is important), and then you dive into documentation for C# programmers and point out how the documentation for C# programmers is telling the C# programmer that if he wants to create a cmdlet he can do it with a C# class. D-oh!

When I point to the PowerShell specification and demonstrates how it does not claim that cmdlets are .NET classes you ignore it.

I point out how it enumerates the 3 different ways to make cmdlet modules: Binary, script and manifest, of which only the binary module variety implement cmdlets as classes.

You could equally well claim that Web Services are just MVC Controllers, because in the documentation for MVC I can find out how to implement web services using MVC controllers.

> ... and they exist within the .NET runtime, which is the relevant issue

Why? If the .NET runtime has become sediment to the point where the OS is always distributed with the runtime, where important OS functions (like troubleshooting) is implemented using the runtime, where remote administration is based on the runtime, at what point do you accept the runtime as part of the OS?

.NET IS part of Windows now, has been since Windows 7 SP1 (IIRC). Troubleshooting packs, guides etc. are written using PowerShell. When your network gets the hiccups, and Windows proactively offers to troubleshoot the network connection, it is PowerShell that is running underneath. The new PackageManager is PowerShell based.

> Thank you, however, for providing yet another demonstration of how PowerShell advocates consistently resort to handwaving, obfuscation, and false claims in order to try to pretend PowerShell is functionally different than it actually is.

No need for snide remarks. I stand by all of my claims. It is you who selectively quote C# programmers documentation out of context. All you have proven is that if a C# programmer wants to create a cmdlet using C#, he must implement it using a class.

Re: “It's easier to port a shell than a shell script” (1998)

#63

Post by useerup »

integraton wrote: post #57
useerup wrote: post #53

Earlier quoted context omitted.

> PowerShell's object pipeline is functionally analogous to function chaining in languages like Ruby, Python, and JavaScript No, in those languages function results are bound upon returning from the function. PowerShell's pipeline would be more like function chaining where each function is a co-routine that can yield partial results, which would make it considerable more complicated. So your attempt at trivializing P…

useerup, virtually everything in your comment is irrelevant handwaving and obfuscation, including a bunch of irrelevant comments about features that are internal to the PowerShell runtime. No matter how much you want to try to talk around it, PowerShell is a .NET CLI, the object pipeline exists within its .NET runtime, and the commands are instances of .NET classes. Unix shells work primarily with arbitrary executabl…

> Here's the cold hard fact stated yet again: PowerShell's object pipeline is functionally analogous to function chaining in languages like Ruby, Python, and JavaScript, not Unix pipelines.

Ok, what then is the functionally analogous function chaining of Ruby, Python or JavaScript to the following:

    cat log.txt -wait | sls "error"
A simple function chain will do.

Re: “It's easier to port a shell than a shell script” (1998)

#64

Post by tatterdemalion »

AnthonyMouse wrote: post #46
tatterdemalion wrote: post #22

Earlier quoted context omitted.

"Text" only makes a good lowest common denominator on UNIX because the designers of UNIX decided that ASCII would be the lowest common denominator of the system. The designers of modern Windows decided that MSIL objects would be their lowest common denominator. If the UNIX designers had chosen some other lowest common denominator, all of these diverse utilities would be communicating over that protocol instead of ASC…

> "Text" only makes a good lowest common denominator on UNIX because the designers of UNIX decided that ASCII would be the lowest common denominator of the system. The designers of modern Windows decided that MSIL objects would be their lowest common denominator. "Text" makes a good lowest common denominator because it's low . Everything, including humans looking at it, can deal with text. Essentially all programming…

Users of System360 computers, which used EBCDIC instead of ASCII, might not agree with you about the inherent portability of ASCII-based text interchange. Not saying .NET objects are as portable, but it's a continuum and a trade off.

Re: “It's easier to port a shell than a shell script” (1998)

#65

Post by tatterdemalion »

kazinator wrote: post #42
MrQuincle wrote: post #28

Earlier quoted context omitted.

Can you explain me a bit the difference if you mind (I don't know much about Windows). In Linux/Unix I can also pipe audio to /dev/audio for example. And image processing through a sequence of steps by pipes is quite often done. Are these objects coming with default metaparameters to make piping easier? Or are there other things implemented that might be cool?

"objects" means data structures. It means you can have some structure with fields, or list or array or whatever as the output of one command, and input of the next one, so the next one doesn't have to do character-level parsing. Of course, this kind of piping is present in nice languages that precede the PowerShell. A one page Lisp macro will give you a left-to-right syntactic sugar for filtering. Clojure has a threa…

This is not what "objects" means (objects have methods), and .NET objects are a much higher level abstraction than structured data.

Re: “It's easier to port a shell than a shell script” (1998)

#66

Post by AnthonyMouse »

tatterdemalion wrote: post #64
AnthonyMouse wrote: post #46

Earlier quoted context omitted.

> "Text" only makes a good lowest common denominator on UNIX because the designers of UNIX decided that ASCII would be the lowest common denominator of the system. The designers of modern Windows decided that MSIL objects would be their lowest common denominator. "Text" makes a good lowest common denominator because it's low . Everything, including humans looking at it, can deal with text. Essentially all programming…

Users of System360 computers, which used EBCDIC instead of ASCII, might not agree with you about the inherent portability of ASCII-based text interchange. Not saying .NET objects are as portable, but it's a continuum and a trade off.

ASCII and EBCDIC are just different ways of encoding the same information. It's like saying comma-delimited files aren't portable because there are also tab-delimited files and some programs support one or the other. It doesn't matter because there are trivial, widely available utilities to convert between them.

There is nothing analogous to convert MSIL to. EBCDIC and ASCII both have a representation for 'A'. Only .NET has "Microsoft.Win32.Registry.CurrentUser.CreateSubKey()".

Re: “It's easier to port a shell than a shell script” (1998)

#67

Post by dang »

integraton wrote: post #60
useerup wrote: post #58

Earlier quoted context omitted.

> You are the same person who tried to falsely claim that cmdlets are not instances of .NET classes The fact stands, cmdlets can be implemented as .NET classes, but they can also be implemented through script (i.e. not .NET classes) or through manifests where cmdlets are generated for WMI/CIM classes. I don't know why you continue to ignore this, or even why it is important. I point out that you are incorrect and poi…

Your statements about cmdlets are simply false, and you are again trying to handwave past the fact that PowerShell is a .NET CLI and that its object pipeline only exists within its .NET runtime and is analogous to function chaining within a single runtime like in Python or Ruby, not Unix pipelines. From the Microsoft documentation, which I quoted to you in a previous discussion, so you should already know it (which w…

Your comments have been crossing over personal attacks. That's not allowed on HN. Please post civilly or not at all.

Re: “It's easier to port a shell than a shell script” (1998)

#68

Post by kbenson »

useerup wrote: post #61
integraton wrote: post #48

Earlier quoted context omitted.

PowerShell's object pipeline only exists within the PowerShell/.NET runtime and is functionally analogous to method/function chaining in languages like JavaScript and Ruby. The object pipeline does not exist outside of the PowerShell/.NET runtime. Pipelines in Unix shells use OS-level functionality to connect standard streams of data, often encoded as text, between arbitrary executables written in any language. The r…

> which is function chaining within a single runtime If PowerShells pipelines are merely equivalent to function chaining, then you should have no problem replicating the following very simple pipeline with function chaining in Ruby, Python or JavaScript: cat log.txt -wait | sls "error" In case you need an explanation for what it is doing: It continously monitors the log.txt file for new lines, and selects those that…

To underscore how the idea of a UNIX shell working on file descriptors between executables isn't really important, it's worth nothing that bash allows piping between it's built in commands/keywords. Not only can you pipe the aggregates output from a for, if or while construct, you can pipe the output of bash builtins such as bg, fg and disown.
Post reply on HN