This PR was merged into the 2.3 branch.
Discussion
----------
[2.3] Remove possible call_user_func()
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Merging this in 2.3 enhances performance a bit, but more importantly will ease future merges into 3.0.
Commits
-------
fad7aba [2.3] Remove possible call_user_func()
This PR was merged into the 2.3 branch.
Discussion
----------
[HttpFoundation] fixed some volatile tests
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | see #11588
| License | MIT
| Doc PR | n/a
Commits
-------
00c1b75 [Process] fixed some volatile tests
974bf01 [HttpKernel] fixed a volatile test
6020c43 [HttpFoundation] fixed some volatile tests
The tests currently fail from time to time if the executing machine is under
heavy load. This leads to false negatives on Travis CI.
A side effect of the change is that the tests are much faster now.
wait() throws an exception when the process was terminated by a signal.
This should not happen when the termination was requested by calling
either the stop() or the signal() method (for example, inside a callback
which is passed to wait()).
This PR was merged into the 2.3 branch.
Discussion
----------
Fix issue described in #11421
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #11421
| License | MIT
| Doc PR | NA
This pull request fixes the issue described in #11421. It also adds a test for the issue. The issue is present in 2.0 forward, but I decided to fix it on the 2.3 branch so that I could also write a test for it (2.0 had no tests for the Process component, and 2.1 and 2.2 didn't have tests for the `ExecutableFinder` class).
Commits
-------
4cf50e8 Bring code into standard
9f4313c [Process] Add test to verify fix for issue #1142102eb765 [Process] Fixes issue #11421
This PR was merged into the 2.3 branch.
Discussion
----------
[2.3][Process] Reduce I/O load on Windows platform
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
When using file handles, no `stream_select` call is done.
On linux platforms, `stream_select` introduce a sleep as it has 0.2s timeout, there is no such pause on Windows, producing lot's of disk I/Os when reading file handles
Commits
-------
ff0bb01 [Process] Reduce I/O load on Windows platform
This PR was merged into the 2.3 branch.
Discussion
----------
[2.3] [Process] Use correct test for empty string in UnixPipes
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
This PR supersedes #11264 : 2.3 compatibility + Windows compatibility + CS fix
Commits
-------
cec0a45 [Process] Adjust PR #11264, make it Windows compatible and fix CS
9e1ea4a [Process] Use correct test for empty string in UnixPipes
This PR was merged into the 2.3 branch.
Discussion
----------
[Process] Disable TTY mode on Windows platform
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
Commits
-------
7942c2a [Process] Disable TTY mode on Windows platform
This PR was merged into the 2.3 branch.
Discussion
----------
[2.3][Process] Remove unreachable code + avoid skipping tests in sigchild environment
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
As mentioned by @Tobion in https://github.com/symfony/symfony/pull/10480#issuecomment-38002910, I removed the dead code. I also fixed/updated the test suite on PHP compiled with `--enable-sigchild`.
Commits
-------
d52dd32 [Process] Remove unreachable code + avoid skipping tests in sigchild environment
This PR was merged into the 2.3 branch.
Discussion
----------
[Process] fix some typos and refactor some code
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
Commits
-------
b422613 [Process] fix some typos and refactor some code
This PR was merged into the 2.3 branch.
Discussion
----------
[2.3][Process] Fix escaping on Windows
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
Windows escaping is broken since the last merges.
After digging more on Windows escaping, I realised some things:
- We forbid environment variable expansion by escaping `%APPDATA%` to `^%"APPDATA"^%`
- We explicitly ask for variable expansion at runtime (running the command line with the [`/V:ON`](https://github.com/symfony/symfony/blob/2.3/src/Symfony/Component/Process/Process.php#L235) flag). Running a command containing `!APPDATA!` will be escaped and expanded (our previous rule is easily overriden)
- On platform that are not windows, we use strong escaping that prevents any variable expansion (`$PATH` will be escaped to `'$PATH'` that is not interpreted as the current PATH)
We have three possibilities:
- Keep this behavior as this.
- Prefer a consistent API and use a strong escaping strategy everywhere, but it would result in a BC break (see #8975).
- Allow environment variable expansion and escape `%APPDATA%` to `"%APPDATA%"`
Any thoughts about this ?
Commits
-------
0f65f90 [Process] Fix escaping on Windows
This PR was merged into the 2.3 branch.
Discussion
----------
[Process] Fixed fatal errors in getOutput and getErrorOutput when process was not started
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #10022
| License | MIT
This PR replaces #9452 and address the latest changes.
Side note : I've not updated `getExitCode`, `getExitCodeText` and `isSuccessful` as they were explicitly tested to return null in case the process is not started or terminated. I think it would be a BC break to do that.
Commits
-------
449fe01 [Process] Trow exceptions in case a Process method is supposed to be called after termination
0ae6858 [Process] fixed fatal errors in getOutput and getErrorOutput when process was not started