`ml` command name conflict with MSVC x86 toolchain `ml.exe`

[TaiXeflar]

Describe the bug

Same as title description.

This bug happens on Windows platform, with using Visual Studio Developer Command Prompt targeting x86 platforms, ml.cmd name will conflict to Microsoft Macro Assembler ml.exe.

To Reproduce

Serveral conditions together will override/conflict:

• Modules/bin in PATH or PowerShell initialized by Modules/init/pwsh.ps1.
• Visual Studio Developer Command Prompt is targeting x86 platforms.

Modules version and configuration

Tested on 5.6.0 version. But It could happens on any version if there's ml.cmd.

Additional context

I was writing some system msvc env detection script with Modules installed on my device, and this happens.

Below is a PrtSc of test result.

This PowerShell is a VS2015 x86 native environment, have Modules/bin not in PATH but initialized by Modules/init/pwsh.ps1.

As we can see, ml.cmd is not in PATH but overrides ml.exe.

[xdelaruelle]

Many thanks for your report.

If I understand well, if both Modules and MSVC x86 toolchain are installed and Modules has been initialized in a shell session, calling ml will reach to ml Modules command. MSVC x86 toolchain is still reachable, but needs to be called ml.exe (with the extension suffix).

I do not see what specific fix should be made. If someone has some clues, I will be happy to hear them.

I see 2 workaround the this issue:

• do not initialize Modules in the shell session when one want to use MSVC x86 toolchain
• if Modules is initialized use full name with extension suffix (ml.exe) to reach MSVC x86 toolchain or undefine the ml function

I should also add a warning in the documentation to make people aware of this name conflict.

Please @TaiXeflar let me know if I miss something here.

[TaiXeflar]

I think this is a "special case" with no need to fix it, but just want to share this.

The major effect is calling program will override the correct program what we want, but in actual make/cmake progress will call the program correctly with their abs path.

Base on the recent develop ecosystem, there's a very less probability where targeting Windows x86 to hit this issue. I think add a warning somewhere in docs/wiki to tell developers to avoid this special env case is fine.