Running dotnet-install.sh from MINGW64 is not supported

[DrewMcArthur]

From within git bash / MINGW64 bash, I ran curl https://builds.dotnet.microsoft.com/dotnet/scripts/v1/dotnet-install.sh | bash and got this error:

dotnet_install: Error: OS name could not be detected: UName = MINGW64_NT-10.0-26200

I'd expect this to just work^(tm)

Thanks!

[ellahathaway]

Root cause

src/dotnet-install.sh only recognizes these uname values in get_current_os_name():

• Darwin → osx
• FreeBSD → freebsd
• Linux → linux / linux-musl / rhel.6

In Git Bash / MSYS2 / MINGW64, uname returns something like:

MINGW64_NT-10.0-26200

That falls through to the error path:

say_err "OS name could not be detected: UName = $uname"
return 1

So the reported failure is consistent with the current script behavior.

Relevant code

get_current_os_name() {
    eval $invocation

    local uname=$(uname)
    if [ "$uname" = "Darwin" ]; then
        echo "osx"
        return 0
    elif [ "$uname" = "FreeBSD" ]; then
        echo "freebsd"
        return 0
    elif [ "$uname" = "Linux" ]; then
        local linux_platform_name=""
        linux_platform_name="$(get_linux_platform_name)" || true

        if [ "$linux_platform_name" = "rhel.6" ]; then
            echo $linux_platform_name
            return 0
        elif is_musl_based_distro; then
            echo "linux-musl"
            return 0
        elif [ "$linux_platform_name" = "linux-musl" ]; then
            echo "linux-musl"
            return 0
        else
            echo "linux"
            return 0
        fi
    fi

    say_err "OS name could not be detected: UName = $uname"
    return 1
}

What I checked

• Verified the current get_current_os_name() logic in src/dotnet-install.sh
• Confirmed that MINGW64_* is not handled there
• Searched the repo for any existing MINGW64 handling and did not find any

Assessment

At minimum, this is a real OS-detection gap for Git Bash / MINGW64.

The open question is whether the script is intended to support that environment. If yes, then this should be fixed by adding handling for MINGW* / MSYS* / possibly CYGWIN* and mapping appropriately to artifact behavior.

Suggested next step

I think the next step is deciding between:

1. Support Git Bash explicitly

   • detect MINGW* / MSYS* / possibly CYGWIN*
   • map to the correct Windows OS identifier
   • verify downstream behavior such as archive type, executable naming, and path handling

2. Document it as unsupported/do nothing

   • replace this with a more actionable error telling users to use PowerShell, CMD, or WSL instead

[baronfel]

More than just supporting the windows OS in the shell script, we'd also need to extend the shell script to support getting the WindowsDesktop runtime - it currently doesn't do that because it was only ever intended for non-Windows platforms.

[ellahathaway]

More than just supporting the windows OS in the shell script, we'd also need to extend the shell script to support getting the WindowsDesktop runtime - it currently doesn't do that because it was only ever intended for non-Windows platforms.

Based on the context @baronfel provided and the fact that these scripts are in maintenance mode, I'm closing this as an unsupported scenario.