Project strategy

[pjmlp]

While we welcome this kind of activities from Microsoft teams, the set of conflicts and commands dropped from the packaging kind of raises questions who is the target group of such project.

Having the commands just blow on Windows and having to come to a table like "Shell Conflicts" isn't really that great developer experience.

Additionally having several dropped commands, which prevent porting scripts that depend on it, when projects like mingw and cygwin have them, also raises some questions.

In the end what is the goal of the project, between shell conflicts and dropped commands, in regards to developers' adoption?

[caomengxuan666]

Great question — this gets at exactly why we chose a different design for WinuxCmd.

Instead of competing with the shell or fighting PATH/alias tables, we take a workspace approach:

• Activate/deactivate — WinuxCmd lives inside a PowerShell session via profile hook, not in global PATH. You opt in per shell, not system-wide
• No PATH pollution — the binary and links stay in their own directory. Only the active session knows about them
• For the two stubborn aliases (cat and rm in PowerShell) — users can simply call cat.exe to bypass PowerShell's built-in alias
• Everything else — ls, whoami, etc. — routes to our implementation by default once activated

This means zero system impact. Install it, try it, and if it's not your thing, delete the folder. No registry entries, no PATH conflicts, no surprises.

Plus being PowerShell user-profile based means it survives terminal restarts naturally without polluting cmd.exe or background processes.

Might be a model worth considering — the opt-in session approach avoids most of the shell conflict problems the current packaging is struggling with.

Docs: https://github.com/caomengxuan666/WinuxCmd/blob/main/DOCS/en/winux_shell_integration_en.md

[caomengxuan666]

And the actual scripts behind this approach:

• PowerShell activation: https://github.com/caomengxuan666/WinuxCmd/blob/main/scripts/winux.ps1 (activate/deactivate/status/list)
• PowerShell profile init (one-time setup): https://github.com/caomengxuan666/WinuxCmd/blob/main/scripts/winux-activate.ps1
• CMD workspace activation: https://github.com/caomengxuan666/WinuxCmd/blob/main/scripts/activate-workspace.cmd
• Link creation (symlink/hardlink entry points): https://github.com/caomengxuan666/WinuxCmd/blob/main/scripts/create_links.ps1

[rubyFeedback]

Additionally having several dropped commands, which prevent porting scripts that depend on it

Well, the current README states that there are plans for some of these such as dd.

dd is indeed useful, I use it on Linux to "burn" CDs/DVDs/USB-sticks (content on USB sticks).

However had, I also actually agree in one other regards, that is for new visitors, to answer
as to why the project was created, what the use cases are. I created a separate issue for
this though. Basically my main focus here would be to improve the documentation, e. g.
to explain to people why this was added. It was recently on hackernews, so more people
may come in the following days, so perhaps it may be useful to add some more content,
explaining the use cases of the project.