PowerShell needs a way to hide commands which won't work #1998
Comments
|
The plan is to allow the variables $IsLinux and $IsWindows so you can use something like: CmdletsToExport = "Get-Process",$(if ($IsWindows) { "Set-ExecutionPolicy" }) |
|
Although I agree this needs to be in the Module Manifest I think that we need to have this information in the Cmdlet (or Function) as an additional property that we can define perhaps like so [CmdletBinding(SupportedOsVersions='Windows','Linux','MacOS')](not sure would need MacOS but best to put it in there) I believe that would be a breaking change but would allow for CI systems to dynamically build the *ToExport lists like @lzybkr has suggested for in the Manifest |
|
It would be convenient to be able to do it with an attribute, but unless putting it in the I'm ok with the |
|
Something could be done using the "Get-CimInstance" cmd, if it works on Linux, of course. |
|
@lzybkr Would this help us with intellisense when e.g. developing scripts for Linux from an instance of VSCode running on Windows? |
|
We need to spend more time thinking through the solution (perhaps a RFC), moving to 6.1.0 |
|
@SteveL-MSFT did the thinking bear fruit that could be shared here? |
|
@mi-hol no investigation for this has happened yet |
|
I am running PowerShell Core 6.1.1 on MacOS, and encountered these symptoms again. I found this issue via #7573. I could add more specific issues to running Set-ExecutionPolicy in PS Core on MacOS, but for this Issue, I think this is sufficient. |
|
Module manifest already supports conditional exporting https://docs.microsoft.com/en-us/powershell/gallery/concepts/module-psedition-support As for the ExecutionPolicy cmdlets themselves, I don't recall exactly why we left them since we explicitly removed others. Let's have Committee review. |
|
@PowerShell/powershell-committee reviewed this, since we want to retain |
|
It seems we hide/remove all that don't work on Unix-s. Can we close the issue? |
For example:
Set-ExecutionPolicy. This command should simply not exist on Linux. Rather than throwingRuntimeErrorExceptionterminating errors, I would prefer to get a command-not found, because that's something I can test for ahead of time.Years of developing for moving targets on the web has taught us that the right way to avoid features that don't exist is to test for the feature, and not for the underlying OS, Architecture, or software version, because you never know when someone's going to finally figure out how to implement something.
If non-functioning commands are not hidden, there is no easy, fast way for scripts to test for whether commands will work -- you have to run them and catch the exception. However, many scripters will instead write incorrect conditional code based on the PSEdition (or operating system sniffing, but currently that's not even in
$PSVersionTable#1997) which will prevent them from using the feature in the case where it's added later on.In general, when a (core) module exposes a command (functioning or not), it's more difficult for another module to provide an implementation -- I know we can't anyway in this particular example, but that's the problem with picking examples ;-)
Suggestion: This should be exposed in the manifest.
I would like an easy way to identify commands that should be exported based on PSEdition, PSVersion, OS, or Architecture from the module manifest.
I don't want to have to wrap binary modules in script modules to put conditional Export-ModuleManifest statements in ... especially since putting the right values in the manifest for exported cmdlets is vital to discoverability.
One thought is to allow specific module manifests for platforms, like
MyModule.Core-Linux.psd1or something -- this would provide solutions to other design problems as well (like loading the right binary assemblies).The text was updated successfully, but these errors were encountered: