uutils.coreutilsからMicrosoft.Coreutilsに引っ越し

Life

coreutilsを使う目的

WindowsでもLinuxコマンドを利用したい

Microsoft.Coreutilsを使う目的

インストールを楽にやりたい

従来のuutils.coreutilsのインストール方法

マルチコールバイナリという特殊な仕組みでは、単にインストールしただけでは ls などを直接実行できず、coreutils ls のようにサブコマンド経由でしか呼び出せなかった。
そのため、PATHが通っているディレクトリにシンボリックリンクを展開することで、ls などのコマンドを直接使えるようにしていた。

winget install uutils.coreutils
$coreutils_path = "${env:LOCALAPPDATA}\Microsoft\WinGet\Links\coreutils.exe"
$expand_path = "${env:USERPROFILE}\.local\coreutils"
New-Item -Path $expand_path -ItemType Directory -Force | Out-Null
$utilsList = @(coreutils --list)
$utilsList | ? {
  $_ -notin @("[")
} | % {
  "${expand_path}\${_}.exe"
} | ? {
  -not (Test-Path $_)
} | % {
  New-Item -ItemType SymbolicLink -Path $_ -Target $coreutils_path
}

新しいインストール方法

winget install Microsoft.Coreutils

インストール時に、C:\Program Files\coreutils\binの中にシングルコールバイナリを展開してPATHも追加してくれる
さらにcoreutilsに加えてfindutils,grepなども追加してくれるので
今までは使えなかったxargs,find,grepなども使えるようになるので、uutil.coreutilsの上位互換と言える

注意点

PowerShellにおけるエイリアスの競合と解決方法

READMEにも記載されている通り、PowerShellでは多くのコマンド名が標準エイリアスと競合し、結果としてエイリアス側が優先される場合がある。

> Get-Alias

このコマンドで現在定義されているエイリアス一覧を確認できるが、プラグインや追加モジュールによるエイリアスも含まれる。そのため、ビルトインのエイリアスのみを抽出したい場合は、SOに記載の手法が参考になる。

解決方法としては、PowerShellターミナル起動時に読み込まれる profile スクリプトを利用し、エイリアスの上書きまたは削除を行うことで競合を回避できる。
coreutils由来に限らず他の標準エイリアスも対象に含まれるが、以下は実際の設定例である。

%USERPROFILE%/Documents/WindowsPowerShell/Microsoft.PowerShell_profile.ps1
Remove-Item -Force "Alias:where"
Remove-Item -Force "Alias:cp"
Remove-Item -Force "Alias:rm"
Remove-Item -Force "Alias:select"
Remove-Item -Force "Alias:sleep"
Remove-Item -Force "Alias:sort"
Set-Alias -Name "where" -Value "where.exe"
Set-Alias -Name "which" -Value "where.exe"

既知のバグなど

本プロジェクトはプレビュー版として提供されており、不具合を前提とした利用が想定されている。
特に Failed to update PowerShell profiles というエラーが頻繁に報告されている。

開発者によると、「一時的に pwsh 7 をインストールすることで回避可能*」とされている。

実際に私の環境でも同様のエラーによりアンインストールが正常に完了しない現象を確認したが、winget install Microsoft.PowerShell により PowerShell 7 を導入したところ解消された。
Windows 11 標準の PowerShell 5.1 環境では、まだ安定性に課題がある可能性がある。
特に本プロジェクトはアプリ本体というよりインストーラー側の処理に依存しているため、テストの難易度は高いと考えられる。Windowsにおけるインストール処理の検証が難しいことは想像できる。

所感

類似のものとして BusyBox も存在し、以前はそちらを利用していた記憶がある。
その後どこかのタイミングで uutils.coreutils に移行したが、詳細な理由は失念している。
現在は、Microsoft.Coreutils を選択するのが最も安定しており、実用上の第一候補になると考えている。