Locate dotnet tool ipy launcher

[BCSharp]

Resolves #1935 by implementing approach 1.

[Copilot]

Pull Request Overview

This pull request implements approach 1 to resolve #1935 by locating the dotnet tool ipy launcher.

• Corrects a typo in the ClrModule documentation.
• Enhances the runner lookup logic in the PythonCommandLine to include fallback via FindRunner and a memory-mapped file check.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/core/IronPython/Runtime/ClrModule.cs	Fixes a typo in the class documentation comment.
src/core/IronPython/Hosting/PythonCommandLine.cs	Adds new using directives, refines runner lookup logic with fallback via FindRunner, and introduces local functions for runner validation.

Comments suppressed due to low confidence (1)

src/core/IronPython/Hosting/PythonCommandLine.cs:333

• Ensure that 'prefix' is non-null and is an actual prefix of 'assembly' to avoid potential IndexOutOfRangeException or unexpected substring values. Consider adding a guard or using a safer extraction method.

var relativeAssemblyPath = assembly.Substring(prefix.Length + 1);

[Copilot]

[nitpick] Swallowing exceptions silently in the try-catch block may obscure underlying issues during runner validation. Consider logging or handling the exception explicitly to aid debugging.

Suggested change

	} catch { }
	} catch (Exception ex) {
	Console.WriteLine($"Exception occurred while validating runner: {ex}");
	}

[slozier]

I assume on Linux/macOS it's similar to Windows where you have ipy.exe and then .store\ironpython.console\3.4.2\ironpython.console\3.4.2\tools\net8.0\any\ipy.dll?

My first impression is that a path comparison with assembly contents seems a bit flaky. Although perhaps it's a Windows thing... For example with paths in Japanese/Korean systems using a different character, how does it all behave? Also network paths use a different slash (although I guess that one is less likely to occur). Anyway, just things to think about.

[slozier]

Hmm, I guess prefix here could be null if it doesn't find anything?

[BCSharp]

Indeed, the test is wrong. Thanks!

[BCSharp]

I am not sure I fully understand your concerns. The differences on Linux/macOS wrt Windows are that the runner is called simply ipy and it uses forward slashes in the path rather backslashes. Handling proper path separators is done by .NET API (e.g. Path) so the code works on all platforms (I have tested on all three). The relative path embedded in the runner is all ASCII, so (I assume) it uses the ANSI Win32 calls on Windows, which works regardless the codepage used, as ASCII is a subset of all Windows codepages. But I don't have a Korean or Japanese Windows installation so I cannot verify this assumption. I suppose theoretically I could have used the ASCII codec is UTF8 to obtain the bytestring to search, but, in case some hypothetical future version of .NET changes the encoding to, say, UTF-16, I'd rather have the search for ipy.exe fail than throw exceptions.

I do not understand your comments about network paths being a potential problem, can you give me an example? Are you thinking about installations on Samba shares?

As for the flakiness, well, it's a heuristic, not a method, so yes, it is somewhat flaky. The content scan is in principle optional, since the actual search happens by file name, but I'd rather keep it in to avoid false positives. It is not unthinkable that we will encounter some scenarios in which this whole heuristic fails, and will have resort to distribute the shell launches as well, as a fallback.

[slozier]

I am not sure I fully understand your concerns. The differences on Linux/macOS wrt Windows are that the runner is called simply ipy and it uses forward slashes in the path rather backslashes. Handling proper path separators is done by .NET API (e.g. Path) so the code works on all platforms (I have tested on all three). The relative path embedded in the runner is all ASCII, so (I assume) it uses the ANSI Win32 calls on Windows, which works regardless the codepage used, as ASCII is a subset of all Windows codepages. But I don't have a Korean or Japanese Windows installation so I cannot verify this assumption. I suppose theoretically I could have used the ASCII codec is UTF8 to obtain the bytestring to search, but, in case some hypothetical future version of .NET changes the encoding to, say, UTF-16, I'd rather have the search for ipy.exe fail than throw exceptions.

I do not understand your comments about network paths being a potential problem, can you give me an example? Are you thinking about installations on Samba shares?

Nevermind, it's all good. It looks like Korean/Japanese systems just render the \ differently but use the same underlying character. As for network paths I don't know what I was thinking (rough night I guess 😄).

[slozier]

Thanks!