Microsoft PowerShell Core For Linux Now Available as a Snap (betanews.com)

Canonical announced on Friday that Microsoft's PowerShell Core is now available on Linux platform as a Snap. From a report: If you aren't familiar, a Snap is essentially a packaged version of a program that can be easily installed on many Linux distributions. Many see it as the future of Linux, as it has the potential to reduce fragmentation. "Built on the .NET Framework, PowerShell is an open source task-based command-line shell and scripting language with the goal of being the ubiquitous language for managing hybrid cloud assets. It is designed specifically for system administrators and power-users to rapidly automate the administration of multiple operating systems and the processes related to the applications that run on those operating systems," says Canonical.

Comments

Excellent news

[OneHundredAndTen]

A piece of software that fills out a much-needed gap in the Linux world. Thanks, MIcrosoft; we could not expect any less from you.

Re:Excellent news

[cayenne8]

I'm trying to figure out in what universe would a use case be made for replacing native, tried and true shells for Linux with some POS from MS?

Re:Excellent news

[bulled]

So what you want is xonsh then?

Re:Excellent news

[MightyMartian]

Most of the advantage of Powershell comes from access to WMI and other core API functions. As an actual shell goes, it's a horrible bloated monstrosity that is the exact opposite of the Unix philosophy. And without a lot of the hooks, or basically some compatibility layer to turn convert Windows API calls into /proc and /etc hooks, one can imagine it will be even slower than it is on Windows, and with limited functionality. And really, the whole philosophy of Powershell, with its OOP nature, comes out of its origins as basically a CLI for .NET. There really isn't anything comparable in the *nix world save perhaps for some of the GUIs out there.

I get it. This is some way to try to attract a wider base to its toolset, and maybe a bit the other way, but I cannot imagine anyone going through the bloat of bringing up a Powershell script when something like bash will be that much faster and far more intuitive for someone steeped in the *nix world.

Powershell and the whole way the Windows ecosystem is evolving makes truer every day that those who do not understand Unix are doomed to reimpliment it badly.

Why?

[devslash0]

Why, oh why, would I install something that is:
- slow
- bloated
- in all likelihood harvesting data behind your back
- trying to replace something which isn't broken (a Linux terminal)
- dependent on .NET
on my machine? {deity_of_choice}, why would I even permit .NET to exist in my system in the first place?

Re:Why?

[Tough Love]

I know right? It's weird, but It's what happens when Microsoft hires the Gnome mafia.

Since at least Wednesday

[RhettLivingston]

I installed this Wednesday to check out a challenge someone posted in a forum.

The challenge was to implement the following powershell script using bash:

param(
[Parameter(Mandatory=$True)]
[datetime]$FromDate,
[Parameter(Mandatory=$True)]
[datetime]$ToDate,
[Parameter(Mandatory=$False)]
[ValidateScript({Test-Path -PathType Container $_ })]
[string]$Directory = '.'
)
Get-ChildItem -Include '*.JPG','*.PNG' -Recurse -Path $Directory | Where-Object { $_.CreationTimeUtc -ge $FromDate -and $_.CreationTimeUtc -le $ToDate } | ForEach-Object { $_.FullName }

The challenge author also specified that the bash script should match the functionality of the above including:

1. Output the full filename one per line that fulfills the requirements
2. I'll totally run the script on a directory that contains some of the more exotic possible file names. (Good luck with that one)
3. Define the parameters the script can take. Meaning two required parameters - FromDate and ToDate - and one optional parameter the directory. If no directory is specified just use the current one.
4. Do validation of the passed in parameters. The directory should exist, the datetimes should be valid datetimes and not something else.
5. And we certainly want tab completion for the parameters and a help that lists what parameters it takes. So the usual bash equivalent of this:
   Code:
   Get-Help .\test.ps1
   test.ps1 [-FromDate] [-ToDate] [[-Directory] ] []

My first thought was, "I can get a bash script to run on any version of Windows and have been happily using bash and tcsh on Windows since Windows 95 in the 90s. Can that Powershell script run on Linux?" Surprisingly, I installed the powershell core snap, copied the script to test.ps1, and ran it with no issues. It doesn't convert me to powershell, but I was surprised the argument didn't hold.

.NET is dangerous to depend on

[jbn-o]

To elaborate on that last point: being dependent on works under the "Microsoft Patent Promise for .NET Libraries and Runtime Components" is considerably dangerous because of the profound limits for software reuse and modification, and because of how limited this "patent promise" is. You cannot deal in the "Microsoft Patent Promise for .NET Libraries and Runtime Components" covered software as you can with free software (which is so named because it respects a user's freedoms to run, inspect, share, and modify the software) under, say, the GNU General Public License version 3 (GPLv3). Here are a few highlights from that article:

"[Under the Microsoft Patent Promise for .NET Libraries and Runtime Components] youâ(TM)re only protected if youâ(TM)re distributing the code "as part of either a .NET Runtime or as part of any application designed to run on a .NET Runtime". So if you add any of the code to another project, then you lose protection and MS reserves the right to use their patents against you.

[...] the protection only applies to a "compliant implementation" of .NET. So if you want to remove some parts and make a streamlined framework for embedded devices, then your implementation wonâ(TM)t be compliant and the protection doesnâ(TM)t apply to you.

That's a huge danger, particularly to anyone used to working in free software where merging code between compatibly-licensed programs is the norm. Your interests as a user (regardless of your technical skill or willingness to learn technical skills) is far better served by the GPLv3 (also covered at the aforementioned article). The GPLv3 is simply far more straightforward and clear about your permissions, and the GPLv3 grants you what you need to deal fully in the software respecting your software freedom the whole time.