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]

@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.