Clarify scope for non-coreutils convenience commands

[caomengxuan666]

Question

After the kill / ps discussions, I think there is a broader scope question:

Should this project accept small Windows-native convenience commands that are not strictly part of GNU coreutils, when they make the native Unix-like command set more useful on Windows?

For example:

• ps pairs naturally with kill, but is usually from procps rather than coreutils.
• top would be useful for process monitoring, but it is even further away from coreutils and is a larger interactive terminal UI.
• Other possible examples might be free, vmstat, which, or similar small Unix-style tools that Windows users often expect in the same environment, even if they belong to different upstream packages.

I don't think all of these should be added automatically. Some may be too large, too interactive, or too far from the project goal. But it would be useful to know the intended policy before opening more command-specific PRs.

Possible policy options:

1. only commands from uutils/coreutils, findutils, grep, and explicitly chosen bundled deps
2. allow small Windows-native convenience commands when they solve a common Windows workflow gap
3. allow them only if they are simple, dependency-free, and clearly documented as Windows-specific extras
4. keep larger interactive tools like top out of scope unless maintainers explicitly approve them

What boundary would you prefer?

[lhecker]

Should this project accept small Windows-native convenience commands that are not strictly part of GNU coreutils, [...]?

If they have an equivalent on either Linux or macOS, are commonly installed by default, and commonly used: Yes, absolutely.
For instance, pbcopy and pbpaste from macOS would be 100% acceptable (in fact, it would be really nice to have).

I consider the boundary to be utilities that aren't commonly installed by default. For instance, I personally really like pv (pipe-viewer) on Linux. But it's non-default and we should probably avoid including it here.

Similarly, some utilities simply aren't commonly used. For instance, more is simply not a good pager, to the point it's almost useless. Despite being a core utility, I would only include it when it's almost free to do so.

It may be worth codifying this in the readme, because I may not maintain this forever.

---

Regarding your examples, kill should definitely be included. Technically that should go into uutils/coreutils, however, not into our repository. They already got a kill command after all.

The commands may be a more difficult sell. which is called where in CMD`. But considering that it's only a builtin and has no equivalent in PowerShell, I believe it's acceptable.

ps does have an equivalent: tasklist. We could consider adding ps but should give it some thought & time. free and vmstat are from the same package as ps on Linux (procps-ng).

[caomengxuan666]

Thanks, that boundary makes sense.

One note about kill: uutils has a kill, but it looks Unix-only today. It uses nix::sys::signal / nix::unistd::Pid, and kill is under the Unix-only feature set. So Windows would still need either an upstream Windows backend or a native implementation here.

For a few commands like this, I think a native Windows implementation is reasonable. That is also what I did in WinuxCmd: implement the useful Unix-like behavior with Win32 APIs, and document the parts that cannot really exist on Windows.

Since #46 already introduced a Win32-native kill, maybe the question is mostly maintenance cost. Reusing uutils would be nice long term, but it likely needs more Windows shimming. The native version already covers the basic behavior, though it should probably get more tests.

For which, I think a small Rust implementation here could also make sense: search PATH, respect PATHEXT on Windows, and print the first matching executable.For a few commands like this, I think a native Windows implementation is reasonable. That is also what I did in WinuxCmd: implement the useful Unix-like behavior with Win32 APIs, and document the parts that cannot really exist on Windows. If we try to import the full POSIX model, we may end up rebuilding something closer to MSYS2 instead of a small native Windows command set.

[caomengxuan666]

I consider the boundary to be utilities that aren't commonly installed by default. For instance, I personally really like pv (pipe-viewer) on Linux. But it's non-default and we should probably avoid including it here.

Another related question: how do you feel about interactive commands like top?

Unlike pv, top is commonly installed by default on Linux and macOS, and users do expect it in a Unix-like command set. But it is also much larger than which or kill: refresh loop, terminal UI, sorting, CPU/memory stats, key handling, etc.

Personally I am also trying to split the top implementation out of WinuxCmd into a separate windows-top project, so I am curious about your preference here before opening anything command-specific.

Would you consider top in scope, or is an interactive TUI process monitor too far away from this project?

[lhecker]

I consider it out of scope for now, as it is not as useful for scripting.

[caomengxuan666]

I consider it out of scope for now, as it is not as useful for scripting.

Makes sense. I agree that top is more of an interactive/TUI tool than a scripting utility. It is still useful for interactive sessions, but keeping it separate for now sounds reasonable.

[a-rookie-of-C-language]

It may be worth codifying this in the readme, because I may not maintain this forever.

我认为对于边界情况或许写入CONTRIBUTING.md是一个更好的选择,但是考虑到大部分使用者和部分贡献者并不会打开CONTRIBUTING.md,在README.md中添加一个链接到CONTRIBUTING.md,这样让使用者无需了解太多细节但是能快速知道这个项目的边界,而对于贡献者来说,则可以在CONTRIBUTING.md了解详细的规则

您认为呢?

[lhecker]

Yeah, that sounds like a good idea. It'd be annoying if README.md grew too long, so creating and linking to a CONTRIBUTING.md seems better to me as well.