Microsoft.Coreutils Installer Script

Summary

This PowerShell script ensures Microsoft.Coreutils commands take precedence over built-ins in both PowerShell and CMD. It installs/updates Coreutils via winget, validates the installed version against GitHub releases, dynamically fetches the conflict table, and applies fixes. Supports -DryRun mode for safe preview, -Verbose mode for live console output, and -CoreutilsPath for custom install locations.

Best Practices for Coreutils Setup

When to Use This Setup

• Cross‑platform development teams: If your team works across Linux, macOS, and Windows, having GNU Coreutils override PowerShell aliases ensures scripts behave consistently everywhere.
• CI/CD pipelines: Automation that relies on standard Unix commands (ls, rm, cp) will run reliably on Windows agents without alias conflicts.
• Developer training: Great for developers learning Unix/Linux tools who want the same experience on Windows.
• Portability: Makes it easier to share scripts across environments without rewriting them for Windows‑specific cmdlets.

When to Avoid This Setup

• Windows‑native scripting environments: If your workflows rely heavily on PowerShell cmdlets or CMD built‑ins, overriding them may cause confusion or break scripts.
• Mixed user environments: Teams where some developers expect PowerShell behavior (ls → Get‑ChildItem) may find the overrides disruptive.
• Compatibility concerns: Certain commands (echo, date) output differently in Coreutils compared to Windows built‑ins, which can break scripts expecting Windows formats.
• Maintenance overhead: Requires keeping Coreutils updated and ensuring PATH/registry settings remain correct, especially in enterprise setups.

Technical Overview

• Winget Integration: Installs or updates Microsoft.Coreutils (skipped in DryRun).
• Version Validation: Compares local version with latest GitHub release tag.
• Path Detection:
  • Auto-detects Coreutils in C:\Program Files\coreutils\bin or C:\Program Files\Microsoft.Coreutils\bin.
  • Allows user override via -CoreutilsPath parameter for non-standard installs.
• Conflict Resolution:
  • Updates PATH to prioritize Coreutils.
  • Removes conflicting PowerShell aliases.
  • Creates CMD doskey macros for conflicts.
  • Skips table headers when parsing conflicts.
• Registry Handling: Ensures HKCU:\Software\Microsoft\Command Processor exists before setting AutoRun.
• Logging: All actions logged to %ProgramData%\CoreutilsInstaller.log.
• DryRun Mode: Preview actions without applying changes. Shows before/after PATH and CMD AutoRun registry values, plus macro file contents.
• Verbose Mode: Forces console output of all log lines.

Usage

1. Run the script in PowerShell with administrator privileges.

2. To preview actions without applying changes:

   .\CoreutilsInstaller.ps1 -DryRun

3. To force console output of all log lines:

   .\CoreutilsInstaller.ps1 -Verbose

4. Combine both for a full preview with live output:

   .\CoreutilsInstaller.ps1 -DryRun -Verbose

5. To override the Coreutils install path (e.g., custom location):

   .\CoreutilsInstaller.ps1 -CoreutilsPath "D:\Tools\coreutils\bin"

6. Logs are written to %ProgramData%\CoreutilsInstaller.log.

Troubleshooting

• Winget not found: Ensure winget is installed and available in PATH.
• Version mismatch warning: Update winget sources or check GitHub releases.
• No conflicts detected: Verify GitHub README structure hasn’t changed.
• Permissions error: Run PowerShell as Administrator.
• Path not found: Use -CoreutilsPath to specify a custom install location.

License

This project is licensed under the MIT License. See LICENSE for details.