`find` command interprets standalone forward slash `/` as a DOS switch instead of a Unix path

[spritetong]

Description

With the Coreutils for Windows release, the find multi-call binary handles both Unix-style find and legacy DOS find compatibility. However, when executing a standard Unix find command and specifying the root or a path using a standalone forward slash /, the parser/dispatcher mistakenly treats / as a DOS-style switch prefix rather than a positional path argument. This triggers the legacy Windows find error.

Steps to Reproduce

Run the following command in a terminal where Coreutils for Windows is active:

Bash

find / -name *.txt

Expected Behavior

The command should be routed to the Unix-style find utility, treating / as the starting directory path for the search.

Actual Behavior

The command fails immediately with the legacy DOS find.exe error message:

Plaintext

FIND: Invalid switch

Environment / Context

• OS: Windows 11

• Installation Method: winget install Microsoft.Coreutils

• Shell: PowerShell 7+ / CMD

[a-rookie-of-C-language]

That is indeed an issue. Using parameter names like /C /I /N /V /OFF /OFFLINE in nthelpers.rs will cause it to be recognized as the Windows implementation of find.exe.

The simplest approach would be to apply a patch directly in nthelpers.rs; however, this is clearly not the fundamental solution to the problem.

We encountered this exact same issue in the winuxcmd project. To resolve it, we utilized a REPL (which I also mentioned in #138). This way, if users need to use the Windows implementation, they can achieve this via cmd /c or powershell -c, while the GNU implementation remains available within the REPL.

That being said, it is a huge change. Until Microsoft approves this approach, I will implement the simplest fix for now.

winux C:\Users\hzz> find / -name *.txt
/Program Files/BlueStacks_nxt_cn/ffmpeg_command_template.txt
/Program Files/BlueStacks_nxt_cn/LICENSE.txt
winux C:\Users\hzz> cmd /c find / -name *.txt
FIND: 无效的开关