done@dunglas

Status: Needs Review

Someone proposed to fail when a var was used, but not provided when calling. Is that something that would be possible?

I need to figure out, but I don't see anything that would make it not possible.

Comments addressed and new throw added.

Doc PR has been added.

Thanks@Simperfit.

I don't agree with this implementation. The new syntax is very specific to the Symfony process now and not suited within the a general Process class. This logic should be split out into some sort of ProcessBuilder that returns the final command line that you then pass to the Process.
Why should the process class know about this syntax? It's not its responsiblity.

@Tobion you can think of this as SQL prepared statements. Note that the Process component doesn't provide any mean to escape shell arguments anymore, exactly like you should not use any for SQL drivers. And also because it is just impossible to properly escape shell arguments (same for SQL btw, when taking portability into account).
Like PHP PDO handles prepared statements directly, it can also be legit to make Process handle "prepared" command lines, to provide portability across OSes for shell placeholders (esp.${FOO} vs!FOO! on Windows, which you can still use if you really don't want to use the Symfony placeholders btw).

PDO provides different methods for prepared statements to separate concerns. Exactly what I'm asking for.

I'm really not convinced that a different design would provide anything better sorry.
This change is the last of a series of moves that turn Process into a properly handled abstraction of command lines and escaping of arguments (which should never have been exposed to userland, like sql arguments.)

Late to the game, but isn't this a BC break for folks using something likeecho "{{ some_var }} foo bar" >> something.j2 where they expect{{ some_var }} to be echoed to a file?

There are probably bc breaks here. that is also why I don't agree with using the same api for this because you cannot control it anymore.

Nobody echoes like that (they dofile_put_contents() instead)
You need to take escaping into consideration when thinking about this.
We already forced ppl tonot escape values on their own (there is no way to do this in 4.0)
So either they doescapeshellargs() on their own, which is totally broken and unsupported.
When done properly, either ppl use the array-way to define command lines, thus cannot use placeholders, either they use env vars already, but the non portable OS-dependent style. - there is no other way for dynamic values.
Last possibility: ppl inject static values that they escaped/wrote themselves (that's your example), which I really don't expect to collide in practice.
All in all, I think this means dynamic values cannot collide in any supported way, and static values are really unlikely to collide.

I would expect that I can run a command with the process component the same way it works on the shell. This is not possible anymore and you have to think and know about Process special behavior now (in addition to correct escaping).

do you have a real-life example?

Nobody echoes like that (they do file_put_contents() instead)

This is rather bold statement. Also I'm not talking about escaping, in my example the user would want to have plain{{ some_var }} foo bar appended to thesomething.j2 file ({{ some_var }} is valid syntax for j2). In 4.0 it would work, in 4.1 it'd be an exception.

IMO if you're not willing to revert the feature there should be a feature flag turned off by default in 4.x and switched to on in 5.x.

@malarzm you were asking about BC break. I explained why I think the collision is more theoretical than practical IMHO.

echo "My template {{ var }}" | bin/console lint:twig kboom

@Tobion sure, but this a constructed example...
In a real app, you'll do (in 4.0, on Linux):
(new Process('echo $TWIG | bin/console lint:twig'))->run(null, array('TWIG' => 'My template {{ var }}');
as there is no other way to inject a value (and running a command to lint a static string is not something "real", you might agree :) )

It's not about if it's real example or not. It's about expectations. Why am I not allowed to run a process that works with the process component? The job of the process component is it make it easier to run processes from PHP, not harder with edge cases that don't work and behave unexpected.

I think Tobias has a point here. Suddenly, your Symfony app can't run commands that contain{{ ... }} (unless you update your code) Of course it's not super common to include{{ ... }} in your commands but I don't think it's impossible at all.

OK, see#26344