How does it behave with #9780 ?

btw, the previous implementation used the PECL extension as a fallback. This should be consistent here

Looks like the same as #9780 (which has already been merged) without the fallback.

not exactly. #9780 sets a process title configured by the command, or nothing when not configured. This one sets a default one (which is then overwritten by the command one hopefully to maintain the feature).

However, I think a better implementation would be to modify the Command process name handling to set the default title when it does not have a custom one

Sorry, I didn't see it was implemented already.

Indeed this PR sets a value by default using the template %app% - %cmd% which would give for example Symfony - doctrine:schema:update.

The advantage I see in putting the handling in the application is the ability to have two different titles for two different applications (with different names) using the same commands without having to set a different title for each command.

However this implementation does not have the fallback as @fabpot mentionned.

I can propose this alternative commit to merge both changes florianv@8b3e3e7

• sets a title by default if the functions are supported
• allows to customize the process title with placeholders

Looks good to me (/cc @lyrixx)

I'm not sure it's really needed to change the title of command like doctrine:generate:entity.
IMHO, the process title should be changed only when it's a long process, like consumers.

More over, you dropped the fallback to the PECL. And in your last commit, you dropped the notice when none of the two functions exists.

Then the default command title contains space. This is not useful when "grepping". On my computer, none process has a title with a space. I think there is a reason for that.

So I'm -1 with this feature.

I think it's nice to have a default value working out of the box for framework users. So if they add a command to their bundle, for example to use in a cron job, it will have a nice title by default without having to call setProcessName. That's why the notice has been dropped.

Considering the usage in grep, I can remove the spaces. But it won't be hard to use because the pattern is known ps -A | grep Symfony - namespace:sleep.
It's also possible to grep easily all Symfony framework processes running ps -A | grep Symfony.

@florianv the notice should be kept if they set a custom process title and we are not able to apply it

I'm -1 on this change. Setting the process title should be opt-in.

I understand the point of not doing too much magic and at the same time it seems easy to set the title with the current handling but I think it will need to be documented after #10474 is merged.
So I close this PR as the placeholders are not needed because we can easily get the application name from the command.

@florianv For your information, you can easily do this on your side, with command events.

@lyrixx thanks. Maybe simpler in initialize(), for example:

$this->setProcessTitle($this->application->getName().'-'.$this->name);

@florianv this would work only for your own commands (so not equivalent to your proposal here). The event allows doing it for all commands

@stof yes while allowing to keep the default title for some commands which is not possible with this PR.