Non-interactive mode fails in Windows environment

[bbuehrle]

Symfony version(s) affected: 5.0

Description
Symfony commands (such as in maker-bundle) which require user interaction throw exceptions when using Windows 10 and Git for Windows.

How to reproduce
I created a new Symfony project using composer create-project symfony/website-skeleton which installed:
- Installing symfony/maker-bundle (v1.14.3)

No other configuration or code was added to the project. When I run bin/console make:entity without any arguments, I usually am put into interactive mode where it asks for then entity name and field definitions. Now, I receive an error:

In Generator.php line 134:

  Argument 1 passed to Symfony\Bundle\MakerBundle\Generator::createClassNameDetails() must be of the type string, null given, called in <snip>\vendor\symfony\maker-bundle\src\Maker\MakeEntity.php on line 135

https://github.com/symfony/maker-bundle/blob/443411aa3c75d87efb07a67f170295ff0961e257/src/Maker/MakeEntity.php#L133-L136

https://github.com/symfony/maker-bundle/blob/443411aa3c75d87efb07a67f170295ff0961e257/src/Generator.php#L127

Environment:

$ php -i
phpinfo()
PHP Version => 7.3.11
System => Windows NT BBDESKTOP 10.0 build 18363 (Windows 10) AMD64

Build Date => Oct 22 2019 11:12:32

Compiler => MSVC15 (Visual C++ 2017)

Architecture => x64

Configure Command => cscript /nologo configure.js  "--enable-snapshot-build" "--enable-debug-pack" "--disable-zts" "--with-pdo-oci=c:\php-snap-build\deps_aux\oracle\x64\instantclient_12_1\sdk,shared" "--with-oci8-12c=c:\php-snap-build\deps_aux\oracle\x64\instantclient_12_1\sdk,shared" "--enable-object-out-dir=../obj/" "--enable-com-dotnet=shared" "--without-analyzer" "--with-pgo"

Server API => Command Line Interface

Virtual Directory Support => disabled

Configuration File (php.ini) Path => C:\Windows

Loaded Configuration File => C:\tools\php73\php.ini

Scan this dir for additional .ini files => (none)

Additional .ini files parsed => (none)

PHP API => 20180731

PHP Extension => 20180731

Zend Extension => 320180731

Zend Extension Build => API320180731,NTS,VC15

PHP Extension Build => API20180731,NTS,VC15

Debug Build => no

Thread Safety => disabled

Zend Signal Handling => disabled

Zend Memory Manager => enabled

Zend Multibyte Support => provided by mbstring

IPv6 Support => enabled

DTrace Support => disabled
Registered PHP Streams => php, file, glob, data, http, ftp, zip, compress.zlib, compress.bzip2, https, ftps, phar, sqlsrv

Registered Stream Socket Transports => tcp, udp, ssl, tls, tlsv1.0, tlsv1.1, tlsv1.2

Registered Stream Filters => convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, zlib.*, bzip2.*
This program makes use of the Zend Scripting Language Engine:

Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies

with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans

Additional context
symfony/maker-bundle#506

[stephen-lewis]

I looked into this. I think it's something very specifically weird with how mintty is configured for git bash. I'm slightly hazy on the details but I keep coming across similar issues with python in the past to do with how mintty integrates with the window console. It appears to pipe (or not) STDIN in some cases - I think that is what is happening, causing stream_isatty() return false despite it actually being an interactive session. (e.g. https://stackoverflow.com/questions/48199794/winpty-and-git-bash)

My clue to this was $_SERVER['_'] - it differs (as does a chunk of phpinfo() and the $inputStream object) between calling techniques.

In the 'working' php ./bin/console way:
$_SERVER['_'] == '/usr/bin/winpty'

In the broken ./bin/console way:
$_SERVER['_'] == './bin/console'

My guess is that php is doing something smart when called directly that /usr/bin/env is preventing somehow.

I tested using cygwin bash in a windows console and both ./bin/console and php ./bin/console worked as expected.

I don't think this is a specific error exactly within symfony/console, but perhaps it is worth coding an explicit check for this in Application:configureIO somehow... I'm not sure how yet.

-- edit: grammar

[bohanyang]

It works when adding "php" before the command, but after input, colors are broken

[bohanyang]

I just believe that everything worked at least around Sept., Oct. 2019 (maybe old version?)

Tested: Symfony 4.4.4 everything OK

[bohanyang]

Today when I create a new 5.0.5 project, it magically worked.
PHP 7.4.3 Symfony 5.0.5

[nicolas-grekas]

OK, closing then. Might have been fixed by @ostrolucky in #33897

[bbuehrle]

Yes, this seems to have fixed the issue. Thanks, all!