Fixing Import-Module on Linux for special cases of NestedModules/RootModule path format #4010
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NestedModules/RootModule are fields in a module manifest (.psd1) that reference other modules using string paths. Assuming that a module is written to be cross-platform, the same psd1 module manifest should be successfully imported on both Windows and Linux platforms.
The bug is that in some cases Import-Module on Linux fails for a totally valid module. It depends on format of NestedModules/RootModule paths.
The root of the problem is using simple Path.Combine for constructing a path to the submodule, that is then tested using NativeItemExists methods, resulting in calls like
Unix.NativeMethods.IsFile("/home/testuser/TestRootModule/.\SubModule\SubModule.psm1")
which fails and Import-Module returns an error.
The fix is to resolve submodule paths using existing FileSystem provider utilities.
Test results on Ubuntu 14 after the fix:

Test results on Ubuntu 14 before the fix:

Fix #3693