[kbenson]

I know enough and have had enough tangential contact with PowerShell to know that it works on a fundamentally different paradigm, as it does not pipe text, but objects. As such, it's hard to say it's "better" since it's so different. I would hazard that it's better some respects for some things, and the reverse is true as well. It fits well into windows, but would not fit well into UNIX systems, where most things are already just text.

I haven't used inforno-shell, es or rc, so can't comment on them directly. That said, if they are easily comparable to bash, ksh, etc, then you probably owe it to yourself to see what powershell is about and why it's fundamentally different.

[vezzy-fnord]

That said, if they are easily comparable to bash, ksh, etc

I specifically contrasted them against Bourne or C-like shells, so I thought that much was clear that they are not.

I have tried PowerShell. I think this comment summarizes it well: https://lobste.rs/s/vzjalp/why_i_dislike_systemd/comments/sh...

[useerup]

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.

[kbenson]

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.

[moron4hire]

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