PowerShell wrapper breaks some common GNU command forms

まず、コミット fe33724 時点の PowerShell ラッパーのソースを使って cat -- -dash.txt、grep、cp のケースを再現し、その後、引数処理をリリースアーティファクトと比較します。ラッパーが -- というファイル名のケースを保持できるかを確認し、その他のどの GNU/POSIX 形式がシェル構文の制限に該当するかを特定します。完了条件には、検証済みの修正または明示的なラッパーのドキュメントを含める必要があります。

With the PowerShell wrapper enabled, I still hit a few GNU command lines that behave in surprising ways.

The clearest one is a filename starting with -:

Set-Content -LiteralPath '-dash.txt' -Value 'dash file foo'
cat -- -dash.txt

Expected:

dash file foo

Actual:

cat.cmd: '-dash': The system cannot find the file specified.
cat: .txt: The system cannot find the file specified.

It looks like -dash.txt is getting split into -dash and .txt. The same shape also fails for me with:

grep foo -- -dash.txt
cp -- -dash.txt dash-copy.txt

This workaround does work:

cat -- .\-dash.txt
grep foo -- .\-dash.txt
cp -- .\-dash.txt dash-copy.txt

I also ran into a few common GNU/POSIX forms that do not survive the wrapper:

find . \( -name "*.txt" -o -name "*.log" \) -print
find . -name "*.txt" -exec grep foo {} \;
[ -f a.txt ]
cat space\ name.txt
ls \[ab\].txt

Some of these are clearly PowerShell-vs-POSIX-shell syntax issues, so I am not claiming they are all coreutils bugs. But they are common command lines from GNU docs / muscle memory, and they are exactly the kind of cases users will try when using this project.

It would be useful either to handle the cases that can be handled, or to document the boundary of the PowerShell wrapper more explicitly. The -- -dash.txt case in particular looks like an argument-passing bug rather than just a POSIX shell compatibility limitation.

Environment:

• Windows 10.0.26200
• PowerShell 7.5.5
• Wrapper source tested from commit fe33724
• Release artifact tested: coreutils-2026.5.29-x64.exe
• SHA256: 23B019D0664F1F5AA2A0C503435F8B52D3C8EEA2AEC1C0609CE21FCE18667281