…nkary)

This PR was squashed before being merged into the 2.3 branch (closes #15058).

Discussion
----------

[Console] Fix STDERR output text on IBM iSeries OS400

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | None
| License       | MIT
| Doc PR        | None

Prior to this PR a Symfony Console command would output error text as random symbols when executed via the IBM console program QSH. Affected error text output such as when a required InputArgument is missing, or when explicitly using `$output->getErrorOutput()->writeln('Some error text here')`.

![Example error output](http://i.imgur.com/PQplK1p.png)

This PR fixes error text so it properly prints to IBM console programs such as QSH and QP2SHELL.

I previously fixed STDOUT for PHP running on IBM iSeries OS400 (Zend Server) using the same approach. Since that PR was merged ConsoleOutput class began using its own output for STDERR which exhibits the same issue STDOUT did.

The following commits and previous Symfony PRs have our relevant discussion about ASCII vs EBCDIC character encoding to fix this issue:

* [Original IBM STDOUT reported in #1434](#1434)
* [My PR #4152 that fixes #1434](#4152)

Thanks!
:rocket:

Commits
-------

23c42ca [Console] Fix STDERR output text on IBM iSeries OS400

This PR was merged into the 2.3 branch.

Discussion
----------

[Console] use PHP_OS instead of php_uname('s')

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #15058
| License       | MIT
| Doc PR        |

The php_uname() function may be disabled for security reasons.

Commits
-------

40e0dc8 use PHP_OS instead of php_uname('s')

…hnkary)

This PR was squashed before being merged into the 2.3 branch (closes #16095).

Discussion
----------

[Console] Add additional ways to detect OS400 platform

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #16053
| License       | MIT
| Doc PR        | None

This PR adds support for detecting the OS400 platform when the PHP function `php_uname()` is disabled. OS400 platform detection was added in #15058 to fix character encoding issues present on OS400. See that PR for more info.

This PR fixes regression introduced in #16053, which did not work on the IBM OS400 server I have access to. The constant `PHP_OS` being checked outputs "AIX" on my IBM OS400 server. I can't say for sure if it works on other IBM platforms... but I preserved this check just in case.

User @eloigranado [commented here](#15058 (comment)) asking if we could switch to using `PHP_OS` constant instead of `php_uname()` because he claims some admins might "[hide] the exact kernel build from any attacker who discovers a remote PHP code execution vulnerability". I personally don't think we should accommodate this use case, but I was able to find alternate approaches.

### Why use case insensitive string matching stristr() instead of in_array()?

Here are the various outputs on my OS400 server:

    echo PHP_OS; // "AIX"
    echo getenv('OSTYPE'); // "os400"
    echo php_uname('s'); // "OS400"

So we have various case issues here, and possible blank values on platforms where OSTYPE var doesn't exist or php_uname() is disabled. Concatenating these optional values together delimited by ; then case-insensitive searching the string for "OS400" seemed like a fair compromise. I would've probably done `in_array()` if case wasn't an issue.

Commits
-------

96a4071 [Console] Add additional ways to detect OS400 platform

…hnkary)

This PR was squashed before being merged into the 2.3 branch (closes #16095).

Discussion
----------

[Console] Add additional ways to detect OS400 platform

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #16053
| License       | MIT
| Doc PR        | None

This PR adds support for detecting the OS400 platform when the PHP function `php_uname()` is disabled. OS400 platform detection was added in #15058 to fix character encoding issues present on OS400. See that PR for more info.

This PR fixes regression introduced in #16053, which did not work on the IBM OS400 server I have access to. The constant `PHP_OS` being checked outputs "AIX" on my IBM OS400 server. I can't say for sure if it works on other IBM platforms... but I preserved this check just in case.

User @eloigranado [commented here](symfony/symfony#15058 (comment)) asking if we could switch to using `PHP_OS` constant instead of `php_uname()` because he claims some admins might "[hide] the exact kernel build from any attacker who discovers a remote PHP code execution vulnerability". I personally don't think we should accommodate this use case, but I was able to find alternate approaches.

### Why use case insensitive string matching stristr() instead of in_array()?

Here are the various outputs on my OS400 server:

    echo PHP_OS; // "AIX"
    echo getenv('OSTYPE'); // "os400"
    echo php_uname('s'); // "OS400"

So we have various case issues here, and possible blank values on platforms where OSTYPE var doesn't exist or php_uname() is disabled. Concatenating these optional values together delimited by ; then case-insensitive searching the string for "OS400" seemed like a fair compromise. I would've probably done `in_array()` if case wasn't an issue.

Commits
-------

96a4071 [Console] Add additional ways to detect OS400 platform