Repository navigation
PowerShell wrapper breaks some common GNU command forms #23
Description
Activity
Um, but I would like to say that it's not coreutils' issue, it's caused by the shell. The wrapper cannot solve all of these problems. WinuxCmd project also faced the same problems. It troubles me a lot that I have to plan to move WinuxCmd into a new shell project via FFI bindings. However making a reliable shell is also another hard challenge. If this project wants to work well, it must run a test suite and identify all unsupported cases so that users and AI agents could use it. In other words, obey the Principle of Least Surprise is necessary, in my opinion. The project's boundaries need to be clearly marked.
Small follow-up: while testing this, I think it would be useful to have a small regression harness for the PowerShell wrapper itself.
Most of these edge cases live in
pwsh-install-template.ps1, not in the individual utilities. A basic test could create a temporary command layout, load the generated wrapper snippet, and check a few representative lines such as:find . -name "*.txt" cat -- -dash.txt cat 'space name.txt' ls '[ab].txt' find . '(' -name "*.txt" -o -name "*.log" ')' -print
That would make future wrapper changes less risky and help separate utility bugs from PowerShell argument-rewriting bugs.
Great catch. added to backlog
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
-:Expected:
Actual:
It looks like
-dash.txtis getting split into-dashand.txt. The same shape also fails for me with:This workaround does work:
I also ran into a few common GNU/POSIX forms that do not survive the wrapper:
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.txtcase in particular looks like an argument-passing bug rather than just a POSIX shell compatibility limitation.Environment:
fe33724coreutils-2026.5.29-x64.exe23B019D0664F1F5AA2A0C503435F8B52D3C8EEA2AEC1C0609CE21FCE18667281