[Console] Use 'mode' command to detect terminal size on Windows
merged branch jcowgill/console-windows-fix (PR #4594)

Commits
-------

bb87a71 [Console] Use 'mode' command to detect terminal size on Windows

Discussion
----------

[Console] Use 'mode' command to detect terminal size on Windows

This PR uses the windows 'mode' command to get the terminal height and width on windows.

I've left in the ANSICON stuff but I'm not sure if that's needed after this.

---------------------------------------------------------------------------

by travisbot at 2012-06-16T10:37:25Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1634120) (merged a490b6ec into f881d282).

---------------------------------------------------------------------------

by fabpot at 2012-06-16T16:17:24Z

ping @Seldaek

---------------------------------------------------------------------------

by Seldaek at 2012-06-16T17:03:22Z

It's a good addition, but you should still use ANSICON first if it's available. mode returns the buffer size and not the window size, which means the lines are not the real terminal height, but the buffer setting. ANSICON has both informations and hence allows you to be more correct. For columns/width both offer equally good information since the buffer size is not bigger than the window.

---------------------------------------------------------------------------

by fabpot at 2012-06-17T10:41:21Z

Can you squash your commits before I merge? Thanks.

---------------------------------------------------------------------------

by jcowgill at 2012-06-17T13:23:01Z

Yes that's fine.

---------------------------------------------------------------------------

by fabpot at 2012-06-18T12:04:43Z

@jcowgill there are still 3 commits.

---------------------------------------------------------------------------

by jcowgill at 2012-06-18T14:59:51Z

Woops, it's done now
Fix built-in server for PHP > 5.4.1
InputDefinition: corrected grammar mistakes and added a @throws declaration
InputDefinition: Fixed unit tests
merged branch Nanocom/master (PR #4609)

Commits
-------

60d371b InputDefinition: Fixed unit tests
c099763 InputDefinition: corrected grammar mistakes and added a @throws declaration

Discussion
----------

[Console] InputDefinition: corrected grammar mistakes and added a missing @throws declaration

---------------------------------------------------------------------------

by travisbot at 2012-06-18T21:46:59Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1650681) (merged c0997634 into 086ff482).

---------------------------------------------------------------------------

by Nanocom at 2012-06-18T21:58:32Z

Wooops, forgot to change unit tests :) Doing this right now

---------------------------------------------------------------------------

by travisbot at 2012-06-18T22:18:42Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1650917) (merged 60d371bc into 086ff482).
merged branch ajessu/php54-server-fix (PR #4484)

Commits
-------

d982bac Fix built-in server for PHP > 5.4.1

Discussion
----------

[FrameworkBundle] Fix built-in server command for PHP > 5.4.1

Bug fix: yes
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes

License of the code: MIT

The router isn't routing with PHP > 5.4.1, unless you explicitly include the name of the controller.

For the default command: `app/console server:run`

localhost:8000/app_dev.php `Works`
localhost:8000/ `Doesn't work (it used to work on PHP 5.4.0`)

There was a change after PHP 5.4.1 which makes the router from the built-in server command not work, when no resource is specified, as the variable `$_SERVER['SCRIPT_FILENAME']` passes the `isset` check.

Changelog: http://php.net/ChangeLog-5.php#5.4.1
- Implemented #60850 (Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router)

The `router` used to rely on the `$_SERVER['SCRIPT_FILENAME']` being set, to return any asset/file if it existed.

This behavior was changed, so that when using PHP's built-in server, the `$_SERVER['SCRIPT_FILENAME']` is now populated with a combination of the document root and the router filename
Patch: https://bugs.php.net/patch-display.php?bug_id=60850&patch=add_router_script_file_name_svr_var&revision=latest)

---------------------------------------------------------------------------

by travisbot at 2012-06-02T09:06:05Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1506479) (merged b85ff7dd into 1541fe26).

---------------------------------------------------------------------------

by ajessu at 2012-06-03T07:16:33Z

Thinking a bit more about this, as I find my solution a bit weird.

I'll do a bit more testing and report back.

---------------------------------------------------------------------------

by fabpot at 2012-06-13T14:30:28Z

Any news on this PR?

---------------------------------------------------------------------------

by travisbot at 2012-06-18T21:20:17Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1650548) (merged d982bac0 into 086ff482).

---------------------------------------------------------------------------

by ajessu at 2012-06-18T21:35:44Z

Updated the solution, and for me, it's ready to be merged now.

I talked about this on Symfony Live with @michal-pipa (the original contributor to this command) and we were trying to avoid touching the filesystem for the check of file existance to skip the server, but I don't think there is any other way (and it's dev mode, it really shouldn't matter much either).

PHP 5.4.1 and up has changed the behavior of `$_SERVER['SCRIPT_FILENAME']` for the built-in server and it's a bit unreliable/ugly to rely on it now.

This fixes the command, it works again for all versions of PHP 5.4.x
A very similar solution was also suggested on internals:
http://news.php.net/php.internals/53870

@michal-pipa any other ideas?

---------------------------------------------------------------------------

by michal-pipa at 2012-06-18T23:14:36Z

I'll take a closer look at this tomorrow.

But I think that you should revert to original behavior and call production front controller by default to be consistent with other servers.

---------------------------------------------------------------------------

by ajessu at 2012-06-19T08:48:17Z

> But I think that you should revert to original behavior and call production front controller by default to be consistent with other servers.

I disagree. This is a development-only server, and thus, the development controller should be called since IMHO it will be the most common use case for the command, development.
If for some reason, someone wants to use their production controller, it's as easy as providing a new router and passing it to the command explicitly.

Let me know if you come up with something else.
[FrameworkBundle][Command]ContainerDebugcommand - Change on method visibility to allow extension