ハクソク

世界を動かす技術を、日本語で。

Windows用Coreutils

2026年6月3日原文(github.com)

概要

  • Windows でも UNIX系コマンド をネイティブに使用可能
  • Microsoft 公式が uutils/coreutils, findutils, grep を一体化
  • Linux, macOS, WSL と同じコマンド・パイプライン互換
  • WinGet やリリースページから簡単インストール
  • 一部コマンドは PowerShell/CMD のビルトインと競合注意

Windows向けUNIXコアユーティリティの概要

  • uutils/coreutils, findutils, grep をまとめた Microsoft公式ビルド
  • Linux, macOS, WSL, コンテナ, Windows 間でスクリプトやコマンドの移植性向上
  • 既存の シェルスクリプト が 無変換 でそのまま動作
  • 各コマンドは --help オプション対応、詳細な使い方確認可能
  • 現在は プレビュー版 として提供

インストール方法

  • WinGet によるインストール
    • コマンド例：winget install Microsoft.Coreutils
  • Release Page から最新版バイナリのダウンロードも可能

シェルでのコマンド競合

  • PowerShell 7.4以降 必須、旧バージョン非対応
  • CMD/PowerShell のビルトインコマンドと一部競合
    • 競合の有無は シェル種類、PATH順序、PowerShellのエイリアス で決定
  • 代表的な競合例
    • cat, cp, ls, rm, sort などは 動作可能 （一部PowerShellと競合）
    • dir, expand, more, paste, kill, timeout, whoami などは 非提供 または 競合で利用不可
    • find, sort, hostname は Windows組込版の拡張 として動作

Windows特有の注意点

  • CRLF改行
    • 通常は自動対応だが、 $でのパターンマッチやバイト数指定 に影響あり
  • /dev/nullの非対応
    • 代替として NUL を使用（例：find . -name "*.log" > NUL）
  • POSIXシグナル未対応
    • SIGHUP, SIGPIPE, SIGUSR 等は利用不可、 Ctrl+C(SIGINT) は動作
  • パス区切り記号
    • /と**両方利用可能、出力は \区切りが多い
  • ファイル権限
    • POSIXパーミッション ではなく ACL で管理、一部コマンドは挙動やオプションが異なる
  • シンボリックリンク
    • 既存リンクの読取は可能、新規作成は 開発者モード または 管理者権限 が必要

提供されないコマンド

  • POSIX依存 や Windowsで無意味・競合するもの は非提供
    • 例： dd, dircolors, shred, sync, uname, chcon, chmod, chown, chroot, mkfifo, stty, who など

コントリビューション

  • バグ報告、プルリクエスト 歓迎
  • 詳細は CONTRIBUTING.md 参照
    • リポジトリ構成、uutils本家との変更フロー について記載

Hackerたちの意見

やっと来た！これは実際にワクワクするね… Linuxのポート（Cygwin、MSYS2、Git Bash）はどれも素晴らしいけど、どれか一つは常にパスに入れてる。でも、MSがそれをメンテナンスしてくれるなら（続けてくれると仮定して）、いいニュースだね。

つまり、dirはビルトインとの競合で出荷されないのに、echoとrmdirは競合してても出荷されるってこと？sortは競合がないと見なされるの？その論理は何なの？

└

AIがそう言った。

└

さっぱりわからない。これ、最初から壊れてるよ。少なくとも、今後どうやってこの混乱を改善するつもりなのか理由を説明してほしい。そうじゃないなら、やらない方がいいよ、扱いにくいなら。

└

CMDコマンドと競合する場合は出荷されないと思うけど、Powershellコマンドと競合する場合は大丈夫なんじゃないかな。

└

hex4def6が言ったように、DOSコマンドの競合は良くないアイデアだし、インタラクティブセッションでPowerShellのビルトインを上書きするのは（PSReadLineで）許容されるけど、あまり良いアイデアではない。私たちはDOS sortをオープンソースにして、DOS findコマンドのポートも公開した。スイートはヒューリスティックに基づいてGNU/DOSのバリアントに振り分けるんだ。

└

おそらく、いくつかのコマンドは、コマンドラインオプションなしで使うと両方のシステムで同じように動作するから互換性があるんだと思う。実装がDOSとUnixのオプションを区別できるんだろうね。

CMDとPowerShellでは、いくつかのコマンドがビルトインと名前が被ってる。Coreutilsのバージョンが動くかどうかは、シェル、PATHの順序、そして（PowerShellの場合は）エイリアステーブルによる。 うーん、これはあまり満足できないね。失敗の根本原因を推測しなくても実際に動く方法を示してくれればいいのに。

└

対象プログラムへのパスを完全に指定すれば、特に問題はないはずだよ。

└

一番面白いのは、PowerShellが何年も前からLinuxコマンドをWindowsの同等品にシムしてたから、たくさんのPowerShellと競合してるってこと。フラグが違ってたのにね。だから、いろんなシステムで「ls」は「dir」の動作に合わせて、dirのフラグだけを受け入れるんだ。でも、ここで新しいcoreutilsリリースを使ってるシステムだと、lsはlsのフラグを期待するよ！

└

もしかして、llmツールのためにPATHを使うってことかな？それが一番納得できる理由だと思ったんだけど。

└

既存のCMDバッチファイルやPowerShellスクリプト、アプリケーションの呼び出しを壊さずに、どうやってこれを解決するつもりなの？

Hacker Newsで議論の続きを見る