Executable name is case sensitive when calling -> unknown program

[romibi]

Calling C:\Program Files\coreutils\bin\false.exe works.
Calling C:\Program Files\coreutils\bin\False.exe results in:
coreutils: unknown program 'False'

The same is true for all other tested executables.

Noticed this, because my windows terminal profile calls clink inject ... which in turn somewhere calls False which then resulted in this message.

My current workaround is to put "C:\Program Files\coreutils\bin" after "..\Git\usr\bin" in the search path which contains a working false.exe, but my goal is to get rid of the git bin folder from the searchpath at some point.

[caomengxuan666]

Yeah, this should be case-insensitive on Windows.

Windows generally treats paths this way, including include paths and executable names, so False.exe resolving differently from false.exe is pretty surprising. I think normalizing the invoked executable name before dispatch is reasonable here and matches the principle of least surprise.

I opened a small fix in #53.

[lhecker]

Yeah, this should be case-insensitive on Windows.

I'm somewhat opposed to this, because for now this seems like a rare edge case. Ideally, people should write and use commands that are mostly portable between Linux and Windows. If we accept False then it will not work on Linux = meh.

Your thoughts?

[caomengxuan666]

Yeah, this should be case-insensitive on Windows.

I'm somewhat opposed to this, because for now this seems like a rare edge case. Ideally, people should write and use commands that are mostly portable between Linux and Windows. If we accept then it will not work on Linux = meh.False

Your thoughts?

Yeah, I get the portability concern.

My thinking here is not that users should write False in portable scripts. They probably shouldn't.

The issue is more about Windows executable lookup semantics. If a file is named false.exe, Windows can still resolve and launch it through a differently-cased spelling, and tools like launchers, terminals, or wrappers may preserve that spelling when invoking the executable. Once the process has already started, the multicall dispatcher using a stricter case-sensitive lookup creates a mismatch inside the same Windows execution path.

So I see this less as accepting a new portable command spelling, and more as making the dispatcher match how Windows already resolved the executable name.

Also, in practice, I don't think this would encourage many users to carry a Windows-only habit back to Linux. Most users who care about Unix command portability probably already come from Linux/macOS/WSL and will naturally type lowercase command names. The reported case seems more like a Windows-side launcher/wrapper preserving a differently-cased executable name than a user intentionally writing False as a portable command.

A similar Windows-only example is include paths: on Windows, #include <Windows.h> and #include <windows.h> often resolve to the same file because the filesystem lookup is case-insensitive. That doesn't make the spelling portable to case-sensitive systems, but Windows tools generally still follow Windows path lookup rules once running on Windows.

That said, if you prefer keeping the dispatcher strict for portability reasons, I can close the PR. I just thought matching Windows executable lookup would be less surprising here.

[lhecker]

Everything you said absolutely makes sense. I don't think you're wrong, but I think it's worth waiting a bit with a PR and seeing how this develops first. The current behavior is indeed overly strict, but the flipside is that we have less variability in the future.

I'm grateful for your reference fix, however! (It looks correct to me; it even uses Cow, which is nice.)

[caomengxuan666]

Ok, roger that. I marked #53 as draft for now.

We can leave this for later. It doesn't seem like a big deal at the moment.

[romibi]

IF you manage to call the next matching executable in the path if the casing doesn't match I wouldn't be opposed to that. But I assume that is more a hack and more difficult.

Also ok for me (but less prefferable) would be a warning/error that can be redirected to NUL but still calling the program code.

If I put microsoft coreutils back to the beginning of the PATH variable I'd get the following output with "where Ls"

C:\Program Files\coreutils\bin\ls.exe
C:\DevTools\Git\usr\bin\ls.exe

In this case calling "Ls" coreutils ls.exe would be run but fail with error output and no normal output.
I only care a little which solution is used. But it shouldn't completely break like this.

Other arguments for handling it case insensitively:

• the tools from git for windows also do it case insensitively
• the ntfs filesystem or windows explorer does not allow differently cased executables with otherwise the same name in the same folder, so in windows environments there can not be a differently cased executable in the same folder.

(I haven't yet found where in clink/oh-my-posh the call to False is triggered but for now I just ensure the git version of false.exe is used)

[caomengxuan666]

IF you manage to call the next matching executable in the path if the casing doesn't match I wouldn't be opposed to that. But I assume that is more a hack and more difficult.

Also ok for me (but less prefferable) would be a warning/error that can be redirected to NUL but still calling the program code.

If I put microsoft coreutils back to the beginning of the PATH variable I'd get the following output with "where Ls"

C:\Program Files\coreutils\bin\ls.exe
C:\DevTools\Git\usr\bin\ls.exe

In this case calling "Ls" coreutils ls.exe would be run but fail with error output and no normal output. I only care a little which solution is used. But it shouldn't completely break like this.

Other arguments for handling it case insensitively:

• the tools from git for windows also do it case insensitively
• the ntfs filesystem or windows explorer does not allow differently cased executables with otherwise the same name in the same folder, so in windows environments there can not be a differently cased executable in the same folder.

(I haven't yet found where in clink/oh-my-posh the call to False is triggered but for now I just ensure the git version of false.exe is used)

Thanks for the extra details. This matches the launcher/wrapper case I was thinking of.

I agree that jumping to the next PATH entry would be more complicated and probably more hacky. I'll leave #53 as a draft/reference for now, and we can revisit if more cases like this show up.