Remove-Module doesn't care about casing, but Import-Module does care

PowerShell Core on Linux.

Steps to reproduce

# this works
Remove-Module psreadline
# this fails
Import-Module psreadline
# you need to run
Import-Module PSReadLine

Expected behavior

Consistent behavior for both cmdlets.

Actual behavior

# this works
Remove-Module psreadline
# this fails
Import-Module psreadline

Environment data

PS /home/aleksandar> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.0.0-alpha
PSEdition                      Core
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   3.0.0.0
GitCommitId                    v6.0.0-alpha.18
CLRVersion
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Aleksandar Nikolić (@alexandair)

Aleksandar Nikolić (@alexandair) Thanks for your report!

I believe if on Unix we allow import different modules modulename and Modulename we should be case-sensitive in Remove-Module and Get-Module too?

Is it a good idea to allow case-sensitive module names considering that Windows will not support such module names as its file system is case-insensitive? Seems like PowerShell should treat modules as case-insensitive. I don't see any value in allowing posh-git, Posh-Git and Posh-GIT to be different modules. I think that would just lead to confusion. IMO all of the module-related commands should be case-insensitive. And if on Linux someone has both mymodule and MyModule dirs. and is trying to import Mymodule, PowerShell should warn the user about the conflict.

If we consider the module names as case-insensitive, then should we do the same in relation to the names of scripts and other PowerShell files?

I don't think so. Script filename casing should following the OS's casing rules. That said, the PowerShell Gallery should consider warning (or rejecting) when publishing scripts that would stomp a different script with the same name on a case-insensitive file system. Either that or use some other means of disambiguation (author name, pub-date, version, etc).

I expect that this will amaze users that .psm1 is case-insensitive and .ps1 case-sensitive.

Loading a module by path doesn't have to follow the same rules as loading a module by name. Considering module "names" are backed by file system names, I'll admit this gets messy. But given that command names in PowerShell are case-insensitive, it seems like the right way to go.

I believe this is an application of the question raised in #706. Ideally, we should address this all up.

Dupe of #1621

fix(probes): use System.Diagnostics.Process for F2 abort exit code

fix(probes): assert F2 abort exit code exactly 1 (#223)

Navigation Menu

Repository navigation

Remove-Module doesn't care about casing, but Import-Module does care #3573

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Remove-Module doesn't care about casing, but Import-Module does care #3573

Description

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Activity

iSazonov commented on Apr 16, 2017

rkeithhill commented on Apr 16, 2017

iSazonov commented on Apr 17, 2017

rkeithhill commented on Apr 17, 2017

iSazonov commented on Apr 17, 2017

rkeithhill commented on Apr 17, 2017

joeyaiello commented on Apr 17, 2017

SteveL-MSFT commented on Oct 12, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions