What about array|string $command instead?

the Process component has explicitly rejected the usage of array|string (we deprecated passing a string to the constructor when introducing the distinction) because the security considerations are totally different between the array of arguments (where escaping is handled internally) and the command line (where the code building the command line is responsible for all required escaping).
So I would vote against an API using array|string for the RunProcessMessage.

i mean if it's a string use Process static constructor, otherwise its regular constructor

having both $command and $commandLine in a regular constructor here, bugs me more :)

What about array|string $command instead?

the Process component has explicitly rejected the usage of array|string (we deprecated passing a string to the constructor when introducing the distinction) because the security considerations are totally different between the array of arguments (where escaping is handled internally) and the command line (where the code building the command line is responsible for all required escaping). So I would vote against an API using array|string for the RunProcessMessage.

Also I find the dedicated method approach more explicit for developper, parameters with multiple type aren't as clear for me.

i mean if it's a string use Process static constructor, otherwise its regular constructor

having both $command and $commandLine in a regular constructor here, bugs me more :)

Yeah that's a good point, maybe a whole other message (RunProcessMessageFromCommandLine ?) would be cleaner ?
Then we could make an abstract that'll be used by both RunProcessMessage and this new message.

personally new RunProcessMessage('ls -a') vs new RunProcessMessage(['ls', '-a']) conveys fine to me.

Otheriwse i'd prefer the current approach yes over a new class.

@ro0NL The case of static command is not the one having security issues.

new RunProcessMessage(['ls', $folder]); // Secure

new RunProcessMessage(\sprintf('ls %s', $folder)); // Insecure

new RunProcessMessage(\sprintf('ls %s', escapeshellarg($folder))); // Secure on Unix system (and partially secure on Windows)

new RunProcessMessage(\sprintf('ls %s', $folder)); // Insecure

It would be passed to Process::fromShellCommandline

new RunProcessMessage(\sprintf('ls %s', $folder)); // Insecure

It would be passed to Process::fromShellCommandline

Yes but the point here is that the user won't know that the call is inherently unsecure, having a dedicated method that is documented as such is better imo

BTW @nicolas-grekas I bisected the php-src to find out why the unit tests fails with php 8.5 and i narrowed it down to those change to reflection: php/php-src#17755
Should I open an issue or should we wait for 8.5 to stabilise before adressing broken components?

Ah nice! Please report to php-src. The earlier the better.

Thank you @Staormin.