Add pwsh support

[ACSimon33]

Hi,
since there seemed to be no progress on the pwsh support ticket, I thought I'd just try it myself.

I've took the hints from the issue and addressed everything which is applicable to pwsh:

• renderFalse procedure to output a false shell statement
• renderTrue procedure to output a true shell statement
• renderText procedure to echo text

renderSettings procedure to:

• define environment variable
• unset environment variable
• define shell alias (if this concept applies to PowerShell)
• unset shell alias
• define shell function (if this concept applies to PowerShell)
• unset shell function

Aliases are defined as functions as well because pwsh doesn't support aliases that contain whitespaces or consist of multiple commands that take arguments.

• execute xrdb command to define XResources
• execute xrdb command to unset XResources

The two above are not applicable to pwsh as far as I can tell (at least on Windows)

• execute PowerShell change directory command
• renderAutoinit to output pwsh code to define the module function for the shell,

The autoinit works only on Unix platforms. On Windows, I defined the the environment and the envmodule command directly in the init script.

• pwsh should also be added to the list of supported shells.

I've tested everything manually on Windows and Linux but I still need to get the testsuite running for pwsh. Also, I probably need to add something to the documentation. In the meantime, any feedback is appreciated.

Best,
Simon

Closes #326

[xdelaruelle]

Many thanks for this contribution. That's great work.

In addition to the code review comment, main point is to add support in the installation testsuite (make testinstall). You will find it in testsuite/install.00-init/. This testsuite will check that pwsh correctly defines variable, function, etc with the commands generated by modulecmd.tcl

On the documentation side, things to add

• How to initialize module on pwsh
• pwsh value returned by module-info shell
• pwsh value returned by module-info shelltype
• update Shell support section

Support for source-sh or sh-to-mod commands may also be added (translate a pwsh script into a modulefile). But it may be the topic of another pull request.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.50%. Comparing base (672e287) to head (c17210a).
Report is 17 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #537   +/-   ##
=======================================
  Coverage   99.50%   99.50%           
=======================================
  Files          15       15           
  Lines        5453     5474   +21     
=======================================
+ Hits         5426     5447   +21     
  Misses         27       27           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ACSimon33]

@xdelaruelle I've added pwsh to the othlang_list in the installation tests because it often doesn't behave like a normal shell. Also, it was easier to write the install_test_pwsh handling the custom module command (envmodule). I fixed most of the things it was complaining about.
One issue is the support for MODULES_REDIRECT_OUTPUT. When we use exceptions as a way to signal an error, there is no way to redirect the message to stdout. And if we write the error message directly to stdout, we have no way of signaling that the command failed. We still can set the LastExitCode, but that is not really the current status code of the shell because it is normally only set by native applications and not pwsh functions/commands.
If we only want to redirect messages from like envmodule --version, that would work.

[ACSimon33]

@xdelaruelle I think I addressed everything now except the support for source-sh and sh-to-mod. I don't see this as an urgent feature because most environment scripts on Windows are still batch files. This can be dealt with in a follow-up PR.
The last thing that we might want to change is the INSTALL.bat script on Windows. The problem is that it puts the module installation directory into the system's PATH variable. This interferes with the module keyword in pwsh. I'd say we just remove that from the INSTALL script. CMD users can just source the init/cmd.cmd, which will set the PATH for them.

[xdelaruelle]

Many thanks Simon for this deep work.

I will take over if I spot some finishing changes to do.

I will test everything on my side.

[xdelaruelle]

@ACSimon33 module quarantine tests are failing so I suspect there is an issue with the code of this feature. Could you please look at it to fix it. If this is too hard or time-consuming for you, I may remove the feature for the moment (could be added later on).

Beware that I have reworked the commits of your branch, so you may pull these changes first, prior to push new commits.

[ACSimon33]

@xdelaruelle […] The last thing that we might want to change is the INSTALL.bat script on Windows. The problem is that it puts the module installation directory into the system's PATH variable. This interferes with the module keyword in pwsh. I'd say we just remove that from the INSTALL script. CMD users can just source the init/cmd.cmd, which will set the PATH for them.

@xdelaruelle Is it ok if we remove the environment variable from the INSTALL.bat script? Alternatively we could create a new install script for pwsh which just copies the files and doesn’t set the env variable. That way nothing would change for CMD users.

[xdelaruelle]

@xdelaruelle […] The last thing that we might want to change is the INSTALL.bat script on Windows. The problem is that it puts the module installation directory into the system's PATH variable. This interferes with the module keyword in pwsh. I'd say we just remove that from the INSTALL script. CMD users can just source the init/cmd.cmd, which will set the PATH for them.

@xdelaruelle Is it ok if we remove the environment variable from the INSTALL.bat script? Alternatively we could create a new install script for pwsh which just copies the files and doesn’t set the env variable. That way nothing would change for CMD users.

@ACSimon33 I prefer no change for CMD users. Could you propose specific INSTALL/TESTINSTALL/UNINSTALL scripts for pwsh?

Subsidiary question: is there a way to automatically setup envmodule when pswh starts? Like done on *sh shells with profile script.

[ACSimon33]

@ACSimon33 I prefer no change for CMD users. Could you propose specific INSTALL/TESTINSTALL/UNINSTALL scripts for pwsh?

Alright, I will create the corresponding pwsh scripts.

Subsidiary question: is there a way to automatically setup envmodule when pswh starts? Like done on *sh shells with profile script.

The path to the profile script for pwsh is stored in the $PROFILE variable. On Windows this is $env:HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1 and on Unix it is at $env:HOME/.config/powershell/Microsoft.PowerShell_profile.ps1 (https://learn.microsoft.com/en-us/powershell/scripting/learn/shell/creating-profiles?view=powershell-7.4#how-to-create-your-personal-profile)

[xdelaruelle]

Many thanks again @ACSimon33 for your deep work on this. Everything seems ready. I will merge the PR as soon as the CI completes.

[TaiXeflar]

Hi,
I just wondering why not just using name modules to solve conflicted name module with pwsh?
the command it just looks like:

 modules av
 modules load ... ... ...
 modules purge

Thanks

[xdelaruelle]

@TaiXeflar envmodule is already the name used on Ruby for the same kind of name conflict than for PowerShell. I also find it less confusing for people not knowing Modules and looking at script using its function: just an extra s may confuse them with the reserved keyword.