Can you please check if this bugfix shouldn't be applied to either 5.4 or 6.3 and rebase/retarget if yes?

@nicolas-grekas Do you meant you want me to see if the bug already exists in 5.4 or 6.3 and rebase if so? It does already exist in both. I've rebased onto 6.3. Is that what you want? Or do you want me to go all the way back to 5.4? (I thought I understood the bugfix policy on this, but maybe I don't.)

This option also has no effect on Windows when the PATH_EXT environment variable is provided.

As this option has been a no-op for other OS since the creation of the process component, I don't think we should change that as a bugfix.

Btw, what is your use case for using this on non-Windows systems ? AFAICT, only Windows automatically adds an implicit extension to the executable name when running it.

what is your use case for using this on non-Windows systems ?

I need to look for executables that may end in .phar--Composer, in this case.

AFAICT, only Windows automatically adds an implicit extension to the executable name when running it.

That is, in fact, the current behavior--and that's the problem. The in-code documentation gives no indication that the behavior is conditioned on OS, leaving no reason for a user to suspect otherwise:

In other words, unless users are expected to search the code before using any and every function in the codebase to see whether it works to their OS, this doesn't behave as advertised. That seems like a bug to me.

@TravisCarden if you need to find an executable named composer.phar, look for that. Because running composer in a shell won't automatically find composer.phar either anyway.

Given that suffixes are totally ignored on non-Windows systems and are ignored on Windows systems that have the PATH_EXT environment variable (which is taken as the source of truth instead), I would rather deprecate those methods in PHP 7.1 than suddenly turning them into doing something.
the current behavior has been implemented in April 2011.

if you need to find an executable named composer.phar, look for that.

I can't, because I'm writing a Packagist package, so I don't know that detail about my end users. Isn't that the point of suffixes?

Because running composer in a shell won't automatically find composer.phar either anyway.

Actually, it will, if I understand you. After applying this PR, and adding composer2.phar to avoid conflict with my global Composer install, it works for me from start to finish:

$finder = new ExecutableFinder();
$finder->addSuffix('.phar');
$path = $finder->find('composer2');
var_dump($path);

// string(28) "/usr/local/bin/composer2.phar"

$process = new Process([$path, '--version']);
$process->run();
var_dump($process->getOutput());

// string(43) "Composer version 2.6.5 2023-10-06 10:11:52"

I would rather deprecate those methods in PHP 7.1 than suddenly turning them into doing something.

Obviously, that's up to you. As I see it, that would make sense if you were talking about adding new behavior that was never claimed or advertised in the first place. But as I argued above, this is how it claimed to work in the first place, so this would just be making good on a promise it has always made but never kept.

Rebased, @nicolas-grekas.

I have my opinion as to whether this is a bug or not, but I don't really care about the semantics if this could be committed to some version. If we can't commit it as-is, can someone tell me what it take?

It doesn't look like the CI failures are from my changes. Requesting re-review.

Oh, of course. Because that test asserts on behavior that is now Windows-only. I've just removed it. I'll go ahead and rebase, while I'm at it.

Thank you @TravisCarden.