Should native Unix-like shells be a target too?

[caomengxuan666]

PowerShell support is useful, but I am not sure it should be the main place where GNU/coreutils behavior is expected to feel natural.

A lot of issues seem to come from the PowerShell boundary rather than from the utilities themselves: parsing, aliases, providers, completions, profile rewriting, signing, install/uninstall behavior, etc. See #23, #119, #122, #151, and #161.

I think this points to a broader question: should Coreutils for Windows serve other shells too, not only PowerShell?

For example, I have been working on winuxsh, a native Unix-like shell for Windows. It does not use WSL/MSYS2/Cygwin and does not create an isolated POSIX environment. It runs Windows-native binaries and operates on real Windows files and processes, while providing Bash-like syntax, pipelines, quoting, globbing, exit-code behavior, and direct .sh script execution.

The goal is not to replace PowerShell. It is to provide a more natural shell surface for coreutils-style commands, without needing PowerShell-specific wrappers and profile rewriting. In my current setup, winuxsh provides the shell layer and WinuxCmd provides the command/coreutils layer.

Would this kind of shell be a useful supported/tested target for Coreutils for Windows, alongside PowerShell and cmd?

[caomengxuan666]

One thing I want to clarify: I do not want Coreutils for Windows to become stuck around PowerShell integration details.

From the issues we have seen, a lot of work ends up being about compensating for PowerShell-specific behavior rather than improving the native utilities themselves: profile/signing problems (#161), GNU command forms through the wrapper (#23), provider paths like env:/alias: (#119), glob/find behavior (#122), and users who want the tools outside normal pwsh behavior (#151).

Those are real integration problems, but they also show why PowerShell should probably be one supported layer, not the only place where Coreutils for Windows is expected to feel natural.