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

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.

I have never used PowerShell, so I don't know a lot about the details. But PowerShell pipes .NET objects from one command to the next, which are not just bytestreams but are objects, with methods and such. It's fundamentally different.

In UNIX, you have bytes, and the underlying system doesn't know what they represent. Most tools assume they're ASCII or UTF-8 (or whatever) encoded text, but that's all they agree on. In practice, you're working almost always working with structured data - tables or lists or mappings - but you have to remember that for the output of this program, you want to cut on '=' and take -f4, and first you need to pipe it through head and tail to clean up some junk output[1], and this other thing for that program, and whatever.

[1] This is a way to get the `time` field from the output of `ping`.

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 reason this is confusing is because one of the main tactics used in PowerShell promotion is to disingenuously compare PowerShell's "object pipeline" to Unix pipelines in order to try to make it appear to be more novel than it is, when they should be comparing it to what it's functionally equivalent to, which is function chaining within a single runtime.

"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 threading operator, Ruby has cascades of dots: object.{ blah }.foo().bar() ... and so on.

This is obviously not what I was talking about. I was talking about data representations heterogenous to the idea of "text".

I used "ASCII" instead of "text" to stress that "text" is just a protocol like anything else. The UNIX I'm running is set to use UTF8.

> 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 PowerShell fails from the start.

For your information, here is roughly how a PowerShell pipeline is set up, processed and torn down:

1. BeginProcess is invoked for each command in the pipeline, starting with the last command of the pipeline, working towards the first. When each command is initialized this way, it can start receiving objects from preceding command on the pipeline. Each command may start produce objects already during this phase, as all subsequent commands are ready to process them. If it produces objects, ProcessRecord of the subsequent command is invoked immediately. 2. ProcessRecord is invoked on the first command of the pipeline. If it yields objects, ProcessRecord of the subsequent command is invoked for each object, thus "pushing" objects through 3. EndProcess is invoked for the first command of the pipeline. It it yields objects, ProcessRecord of the subsequent command is invoked for each object. When EndProcess completes for the first command of the pipeline, EndProcess is invoked for the subsequent command and so forth until EndProcess has been invoked for all commands of the pipeline.

As you can see, each cmdlet has 3 phases: initialization, processing and completion. All cmdlets (functions?) become active at the same time, with the control flow passing to each command (function?) multiple times during each phase. This can be implemented in any turing complete language, but function chaining is a lame attempt at trivializing it. Throw in reactive sequences and it may get closer.

Consider how Sort-Object (alias sort) is implemented: It does nothing during BeginProcess, during ProcessRecord it adds to an internal collection but does not yield any objects (yet), during EndProcess it sorts and yields all of the collected records. This is clearly analogous to how sort in byte/text stream is implemented: When the process starts it does nothing but initialize and starts listening on stdin, for each "line" on stdin it adds to an internal collection, and when stdin is closed it sorts the collection and writes the "lines" to stdout. 3 phases.

Even so, it doesn't really matter how it is implemented, a shell is inherently about how you interact with the shell.

> PowerShell's object pipeline does not exist outside of the .NET runtime and you can not stream objects between arbitrary executables outside of the .NET runtime.

You are locked in the Unix view of the world and is unable to consider that long standing assumptions about "the way to do it" may need a refresh. If you want to leverage objects for system management then yes, you need a system-wide object model. Unix was not built with an object model. Windows was sort-of build with an object model (handles) but it is not versatile enough as a system-wide management model.

However, the good thing about objects is that they are abstractions which can easily wrap existing operating system concepts, such as files, processes, access control lists, drivers, users, groups, network connections etc. .NET is a mature object model and with a lot of tooling. Building PowerShell so that the abstractions over network adapters, users etc become represented by .NET classes enable a lot of tooling and infrastructure right from the beginning.

That comment is utterly uninformed.

If you want to run a script simultaneously on a number of hosts, you use the Invoke-Command cmdlet (or it's alias icm).

If you want to stop a process, you use Stop-Process (or it's alias kill).

To copy files or directories you use the Copy-Item cmdlet (or one of it's aliases cp and copy).

Hence, to stop WINWORD on a host1, host2 and host3 and then copy a directory from host0 to each of them, you would write:

    icm host1,host2,host3 {kill -name WINWORD; cp \\host0\C$\source C:\dest }

As simple as it should be!

The commenter is correct that you cannot start an application in another session from remote. However, this is a security restriction that prevents cross-session contamination and shatter attacks. It is a (security) limitation of Windows, not of PowerShell.

Under Windows, all services run in session 0, the interactive user run in session 1, and if more users log on (e.g. remotely through PowerShell) they are each created in their own session. Windows put severe restrictions on what programs can do cross-session - even if the processes run under the same user account: They cannot send messages, interact with the desktop windows, inject code, start threads etc.

The commenter also alludes to other security settings that you'll encounter when you first start using PowerShell: - Execution of script files are disabled by default. You need to use the Set-ExecutionPolicy cmdlet to allow script execution, and for desktop editions you need to enable remote management. Both has secure-by-default values.

To enable script execution:

    Set-ExecutionPolicy RemoteSigned LocalMachine

I.e. scripts that originates from the Internet (downloaded through a browser or received through mail/IM/etc) or other untrusted zones require digital signatures to run; locally authored scripts are allowed to run with no digital signatures.

To enable remote management run this command:

    Enable-PSRemoting

On Windows Server versions it is now assumed that the administrator will want to use remote management, so it is enabled by default for servers. For desktops you'll need to set it through a group policy or with the command above.

The only attribute you contrasted was how they compare to powershell on the axis of better or worse, and I just stated my belief that it's hard to compare them accurately due to fundamental differences. That's not a strong basis for me to make assumptions about those shells.

By asking if inferno-shell and friends were easily comparable with C-like shells I was attempting to determine if they were additionally hard to compare with powershell, and infer from that your unfamiliarity with powershell. That, obviously, was a stretch.

That's because shells on Windows aren't management tools. That role is filled by Group Policy.