All CLA requirements met.

I used ShellCheck as a linter locally, as it seemed to create the same output as Codacy. I also noticed some of the files contained invalid bash (if then if instead of if then fi), which has also been resolved.

Ilya (@iSazonov) thanks for the great suggestions! I was not entirely sure about the correct casing for Visual Studio Code, as I could find it as VSCode, vscode and VS Code. Because of this I decided to just leave it all lowercase. I have implemented your suggestions, thanks for the review!

It appears the connection to windowsitpro.com has timed out, which is why the static analysis has failed. The next connection to it however does finish successfully. Should the CI be restarted or is this not an issue?

Restart CI-static-analysis.

Darwin (@DarwinJS) Would you mind giving this a first pass?

Okay... I tried to add support to the CI for a representative portion of the distros.

AmazonLinux image failed because it was missing adduser. (I'll ask in the docker repo if we want to add this to get this scenario working.)

OpenSUSE failed because it Azure DevOps could not find pwsh (I can fix this later)

So CentOS testing was the only distro added. cc Aditya Patwardhan (@adityapatwardhan)

Travis - Amazon optimizes every purpose specific use of Amazon Linux and of course specifically the one for containers.

Since the size of the Amazon built Amazon Linux containers affects their server density globally across all customers, it will likely be necessary to add back what you need to get CI running.

PS For my local testing of Amazon Linux 2 - I have actually created some antipattern containers that have the entire EC2 build version: https://cloudywindows.io/post/three-amazon-linux-2-containers-for-testing/

Bram Crielaard (@Geweldig) - did you test your changes on the major distros?
Travis Plunk (@TravisEz13) - how do we know what distros these install scripts are tested on - is there a manifest somewhere?

Darwin (@DarwinJS) I have verified it to be working for the following operating systems:

• Centos7
• Ubuntu 18.04
• Debian 9 (Assuming lsb-release has been shipped with it, might be worthwhile to look at an alternative check as it is not always included)
• Fedora 29
• macOS 12

Which should cover the major distros. I have tried the installer on openSUSE Leap 15 (as 42.3 is reaching EOL in July) where I have not been able to get it to work. However, when trying to run the script which is currently on master I couldn't get it to work either. This problem is twofold, as the OS is not recognized by the main script and the openSUSE installer which is currently provided contains invalid bash. Unfortunately I am not familiar with openSUSE and would need some time to figure out why it currently is not recognized by the script on master and find a robust solution to recognize the operating system.

Darwin (@DarwinJS) The CI YML for testing these scripts is here:

NOTE: where a container is listed, it overrides the pool. Like on line 54, to switch to CentOS.

Currently Ubuntu 16.04, CentOS 7, and macOS Mojave are in the list.

Is it ok if I reverse these changes?
Amazon Linux 2 install is not working whether using the stand alone script or the main one. I'm not sure how many more are doing that?

Why revert? Do you know the issue root cause? Is it possible to fix?

I don't know the root cause, but I let this slip through without realizing the distro fingerprinting had been altered to DEPEND on the parent script being called for each distro specific script. I had specifically designed it to not depend - the parent script was a convenience when wanting to target distros homogenously.

But then I wanted to get off using my original merge branch for linuxmint support which still works for Amazon Linux - and this one does not. (I use it here to create Amazon LInux 2 containers that have PowerShell: https://gitlab.com/DarwinJS/amazon-linux-2-container-with-powershell/blob/master/Dockerfile#L4)

So this all points to the changes not being comprehensively tested - something I was doing whenever I made broad-based changes.

Since these changes seemed to be mainly making the code prettier - not more functional - I'd rather revert to a known working state that I had tested across all distros - than try to fix and retest on all distros. I really don't have the time for the latter.

Bram Crielaard (@Geweldig) Travis Plunk (@TravisEz13) Thoughts?

Darwin (@DarwinJS) I have verified it to be working for the following operating systems:

• Centos7
• Ubuntu 18.04
• Debian 9 (Assuming lsb-release has been shipped with it, might be worthwhile to look at an alternative check as it is not always included)
• Fedora 29
• macOS 12

Which should cover the major distros. I have tried the installer on openSUSE Leap 15 (as 42.3 is reaching EOL in July) where I have not been able to get it to work. However, when trying to run the script which is currently on master I couldn't get it to work either. This problem is twofold, as the OS is not recognized by the main script and the openSUSE installer which is currently provided contains invalid bash. Unfortunately I am not familiar with openSUSE and would need some time to figure out why it currently is not recognized by the script on master and find a robust solution to recognize the operating system.

OK, then maybe the solution is to consider Amazon Linux 2 a major distro and test and debug for it. Not only is Amazon treating it this way, but it was the first distro to have prebuilt cloud image template (AMIs) from the cloud provider with .NET Core and PowerShell Core preinstalled. That is a full Ec2 image, I want to use amazon linux 2 w/ PowerShell Core under Gitlab CI on Linux containers - so still need installation support.

Darwin (@DarwinJS) I indeed didn't test the install script on Amazon Linux 2, as I did not have access to a build environment for it. However, I believe the changes made to the install script shouldn't have broken anything as they only cleaned up unused and broken variables, but I'm obviously wrong. All changes which I believe could break the build on Linux, should also break all other scripts which we have tested to be working.

Do you have a specific error so we can pinpoint where the script goes wrong?

I have concerns about the rollback since the PR has been merged for a long time (we have a release after that).

I did not have access to a build environment for it.

Maybe you could cooperate with Darwin (@DarwinJS) directly?

The following Docker commands will let you easily test:

# This Works:
docker run -v -it amazonlinux /bin/bash -c "curl -s https://raw.githubusercontent.com/DarwinJS/PowerShell/installpsh-debian-support-for-linuxmint/tools/installpsh-amazonlinux.sh | bash ; pwsh"

# This Does Not:
docker run -v -it amazonlinux /bin/bash -c "curl -s https://raw.githubusercontent.com/PowerShell/PowerShell/master/tools/installpsh-amazonlinux.sh | bash ; pwsh"

Ah I see what the problem is, I rewrote the OS checks in a single script and copied them over all other scripts. However, the script I originally based it on seems to not have included the check for amazonlinux. Not sure how I missed that, but it shouldn't be difficult to fix.

Darwin (@DarwinJS) I have opened #9967 to fix this issue, I'm currently verifying the install scripts again on all different operating systems. This has resolved the problem for amazon linux.

Ilya (@iSazonov) Darwin (@DarwinJS) Bram Crielaard (@Geweldig) We have started to move the packaging/installation tools into separate repos that are maintained by the people that care about that tool. Honestly, long term I think we should do the same thing here. We could keep the main script with a warning to migrate.

cc Steve Lee (@SteveL-MSFT)

Travis Plunk (@TravisEz13) Could you please reference the new repo?

Ilya (@iSazonov) This is a concept. There is no current. But Docker and Snap have been separated, if that is what you are talking about.