On finishing the job of replacing system commands

[jhudsoncedaron]

As you probably noticed, the replacement mechanism doesn't work properly when the current directory is C:\Windows\System32 (which wouldn't be that bad if it weren't the default directory of an elevated command prompt).

I considered literally clobbering the commands in Windows\System32 so the coreutils commands would be found. This is not recommended due to servicing reasons.

Thus, I filed https://aka.ms/AA11lcib for the Windows side of it.

If Microsoft actually listens to me they'll move find into its own package so it can be uninstalled independently; but if not we may find ourselves in the position of rebuilding the replace and tree commands as well. Tree is trivial; if I knew Rust I could do so immediately. Replace is not.

[lhecker]

The behavior you mention is specific to CreateProcess and CMD. Both prefer the current working directory over the PATH for executable lookups (very unfortunately).

Which of the two do you consider an issue here? Or did you mean both?

[jhudsoncedaron]

Leonard Hecker (@lhecker) : Ah good question; I do in fact mean both. Nothing can be done unless Windows makes it possible to uninstall or relocate the base components so these components can take over. So yeah; this issue and the corresponding issue on Feedback hub are linked issues.

[a-rookie-of-C-language]

A REPL maybe ok.

Originally, winuxcmd contained a small REPL that intercepted command execution. Later we split that functionality into a separate project (winuxsh).

As a side effect, this largely avoids the command resolution issues caused by CMD/CreateProcess searching the current directory before PATH, because command lookup happens inside the REPL before CMD performs its own executable search.

What does the REPL do?

• Unix-style commands are resolved by our REPL first.
• Unknown commands are delegated back to the parent CMD or PowerShell session.
• sudo support and so on

details:
unixwin/WinuxCmd@73d9d9d

But this isn't the coreutils's responsibility.

[jhudsoncedaron]

Update: found a simpler way to accomplish most of the job; doesn't seem to have weird side effects:

C:\Windows\System32>ln -s "C:\Program Files\coreutils\bin\find.exe" find.com
C:\Windows\System32>ln -s "C:\Program Files\coreutils\bin\sort.exe" sort.com

Thankfully, adding the .com files won't mess with servicing.

[a-rookie-of-C-language]

This does seem like a possible solution, but I'm not sure whether it's worth adding a patch specifically for a scenario that only occurs in cmd (e.g. when running from C:\Windows\System32).

From the coreutils perspective, this arguably falls outside the scope of what coreutils is supposed to handle. However, the README.md also states:

the same commands, flags, and pipelines work the same way, so existing scripts carry over without translation.

That expectation suggests users may reasonably expect these kinds of Windows-specific inconsistencies to be handled somewhere in the stack.

As mentioned in #5:

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

Because of that, it may make sense to consider adding some compatibility workarounds in coreutils for now, at least until the CMD and PowerShell ecosystems can cooperate with coreutils more seamlessly.

[a-rookie-of-C-language]

I think an E-needs-discussion label would be appropriate.

[spritetong]

Hey everyone, just wanted to drop a quick suggestion on how we could handle argument parsing for find.exe to make it a bit more robust in mixed environments.

The Idea

When parsing arguments (especially from argv[1] onwards), we should probably only treat a / argument as a Windows flag if it matches the exact options native find.exe actually supports:

• /V, /C, /N, /I, /OFF, /OFF[LINE] (case-insensitive)

If someone passes anything else starting with a slash (like /etc/hosts, /c/Users/, or /logs), the parser shouldn't blow up with an "unknown switch" error. Instead, we should just treat it as a Unix-style path.

Why this makes sense

• It fixes Git Bash / MSYS2 / WSL edge cases: People running cross-platform scripts or using tools like Git Bash constantly pass Unix-like absolute paths. If the parser assumes every single slash means a Windows flag, it breaks a lot of daily workflows.

• Super low chance of collisions: Let's be honest, nobody really names a file or folder just /v or /c without an extension in the real world. By limiting the flag matching strictly to the official list, we perfectly preserve all native Windows functionality while keeping things smooth for Unix-style paths.

[a-rookie-of-C-language]

Sprite Tong (@spritetong) If you can change your comment to #149 will be ok