Alias conflict strategies and Windows-native design approach — from WinuxCmd project

[caomengxuan666]

Hi Microsoft Coreutils team — I noticed your project while working on WinuxCmd (https://github.com/caomengxuan666/WinuxCmd) and wanted to share some notes from a different approach to the same problem space.

WinuxCmd takes a Windows-native design philosophy rather than a Linux-to-Windows port. Commands are reimplemented from the ground up for the Windows environment — no WSL, no MSYS2, no POSIX layer. ~900KB single binary, 148 commands, designed to work with Windows tools in the same pipeline (netstat -ano | grep 8080 works out of the box).

The alias conflicts documented in your ⚠️ table (cat, cp, rm, ls conflicting with PowerShell aliases) are exactly what we ran into. Our solution: scripts/create_links.ps1 sets up individual symlink/hardlink entry points at install time, and parent shell detection automatically routes unknown commands back to the parent cmd/PowerShell — so users never get stuck wondering "which version is running?"

One more thing: your README marks kill as 🛑 not shipped due to no POSIX signals, but we found process enumeration + terminate by PID works perfectly fine on Windows. Worth reconsidering if users ask for it.

Shell integration docs: https://github.com/caomengxuan666/WinuxCmd/blob/main/DOCS/en/winux_shell_integration_en.md
Scripts: https://github.com/caomengxuan666/WinuxCmd/tree/main/scripts

Different approaches, same problem space. Happy to exchange notes. Keep up the great work!

[lhecker]

I wasn't aware of your project! It looks very interesting.
And thank you for offering your advice. It may take me a bit to get around and check it out, however.

[caomengxuan666]

One deeper issue worth mentioning — the shell itself is often the real problem, not the commands.

Take xargs for example. In PowerShell, piping to an external command goes through object serialization rather than raw byte streams. The quoting and escaping rules are entirely different from POSIX shells. A xargs implementation that works perfectly in CMD or bash will behave unexpectedly in PowerShell — not because the command is wrong, but because the shell rewrites how arguments are passed.

We ran into this across multiple commands during WinuxCmd's development. The conclusion we arrived at: the shell is the root problem. CMD and PowerShell each have their own argument-passing semantics, and neither fully matches POSIX. If you want full POSIX script compatibility, you need a POSIX shell — plain and simple.

What you _can_ do is make individual commands work well in each shell by being shell-aware (detecting the parent shell and adjusting quoting/escaping accordingly). That's what we do. But there's a ceiling — bash scripts with pipes, subshells, and redirections will never work transparently in PowerShell or CMD, no matter how well the individual commands are implemented.

So the practical answer: for interactive use or simple pipes, shell-aware coreutils work great. For bash scripts, WSL or a real POSIX shell remains the right tool. Acknowledging this limitation honestly is better than pretending the gap doesn't exist.

[caomengxuan666]

Another big one your team will face: wildcard (glob) expansion.

In GNU/POSIX, glob expansion is the shell's job, not the command's. When you run ls *.txt, the shell expands *.txt into a.txt b.txt before ls even starts. The command never sees the wildcard — it only sees the resolved file list.

On Windows, neither CMD nor PowerShell does this. They pass *.txt as a literal string. So rm *.txt in PowerShell just tries to delete a file literally named *.txt — unless the command implements glob itself.

I checked your actual code. In main.rs (line 66-70), there is a comment claiming you are not using uucore::args_os() because it globs on Windows:

// NOTE: We're not using uucore::args_os() here, because that performs globbing on Windows,
// which breaks various utilities, such as `find . -name "*.txt"`, where *.txt gets
// immediately expanded to whatever .txt files are in the current directory.
//let mut args = std::env::args_os();
let mut args = uucore::args_os();

But looking at the actual uucore Cargo.toml, the parser-glob feature is NOT enabled (default is ["signals"] only). Without parser-glob, uucore::args_os() falls back to std::env::args_os() — meaning no glob expansion happens at the entry point. The comment is misleading.

The real picture: glob is neither done at the entry point (disabled) nor inside individual commands (because they are inherited from uutils upstream, which assumes the shell handles it). This leaves a gap — commands that users expect to work with wildcards (rm *.txt, cp *.txt backup/) will silently fail or behave unexpectedly in PowerShell and CMD on Windows.

Since this repo is a wrapper around upstream uutils crates, adding shell-aware glob expansion would require either:

1. Enabling entry-point glob and fixing every command that breaks (like find -name "*.txt")
2. Modifying each uutils command to handle glob internally
3. Adding a glob layer between the dispatcher and the command calls

None of these are trivial for a packaging layer.

For comparison, WinuxCmd handles this with a unified glob_expand() inside each command, combined with parent shell detection and \x01 quote protection markers. It is a workaround, not a solution — the clean fix would be a proper POSIX-like shell that handles glob. But at least it acknowledges the problem rather than leaving it as a silent failure.

[lhecker]

I really appreciate you helping us (and specifically me) but it would help me a lot if you could avoid using LLMs for drafting these responses. As an OSS maintainer of multiple projects, I need to read a lot of comments and LLMs are very verbose.

Regarding pipes: PowerShell 7.4 and later has the PSNativeCommandPreserveBytePipe feature. As long as you don't use function wrappers, xargs will work as expected. To avoid such wrappers, I hook into PSReadLine to rewrite the command before execution. To avoid issues with quotes, I use binaries with a .cmd extension, which PowerShell then treats as legacy applications by default.

Regarding the args_os code: Thanks for pointing it out! I'll fix that comment. Edit: #12