Running dotnet-install.sh from MINGW64 is not supported #715

Activity

1. github-project-automation

   added this to .NET Install Scriptson May 6, 2026
2. github-project-automation

   moved this to Backlog in .NET Install Scriptson May 6, 2026
3. github-actions

   added

   untriagedIssue is awaiting triageIssue is awaiting triage

   on May 6, 2026
4. ellahathaway commented on May 21, 2026

   

   ellahathaway

   on May 21, 2026

   Member

   More actions

   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
5. baronfel commented on May 21, 2026

   

   baronfel

   on May 21, 2026

   Member

   More actions

   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.
6. ellahathaway commented on May 22, 2026

   

   ellahathaway

   on May 22, 2026

   Member

   More actions

   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.
7. ellahathaway

   closed this as completedon May 22, 2026
8. github-project-automation

   moved this from Backlog to Done in .NET Install Scriptson May 22, 2026
9. ellahathaway

   removed

   untriagedIssue is awaiting triageIssue is awaiting triage

   on May 22, 2026