[winpty] output is not a tty

[maxime-pasquier]

Hi,
I have an issue with the winpty aliases: it brokes the TTY ?

How to reproduce:

$ unalias php

$ winpty php -i | grep "PHP Version"
output is not a tty

$ php -i | grep "PHP Version"
PHP Version => 5.6.15
PHP Version => 5.6.15

Is it necessary to use winpty ?

[maxime-pasquier]

Meanwhile some explications, if you want to remove all the winpty alias, use this command:

# remove winpty alias
unalias $(alias | grep winpty | cut -d"=" -f1 | cut -d" " -f2)

Or just the winpty PHP alias, use this command:

# remove winpty PHP alias
unalias $(alias | grep winpty | grep php | cut -d"=" -f1 | cut -d" " -f2)

[dscho]

FWIW there is a much, much easier workaround than to unalias anything:

php.exe -i | grep "PHP Version"

And no, we cannot simply abandon winpty. PHP can be run interactively, i.e. it requires a proper Win32 Console. Running PHP without winpty in MinTTY would not provide that Console instance, leaving you with a seemingly unresponsive terminal. See git-for-windows/build-extra@44ed99b, #399 and #400 to understand what havoc you would wreak by simply removing those aliases.

[maxime-pasquier]

FWIW there is a much, much easier workaround than to unalias anything:
php.exe -i | grep "PHP Version"

I cannot specify php.exe for some commands, it is not cross platform safe!

PHP can be run interactively

Yes, but it is not the default use of PHP, it requires : php -a
So maybe we could create an other alias name phpi or phpa just for winpty php?

What do you think about it?

[dscho]

Yes, but it is not the default use of PHP, it requires : php -a
So maybe we could create an other alias name phpi or phpa just for winpty php?

No, that would break it again for the people who reported those issues! They call php -a as you suggested, and nothing seems to happen!

[maxime-pasquier]

No, that would break it again for the people who reported those issues!

Maybe I am wrong, but I have not found reported issues for PHP?

They call php -a as you suggested, and nothing seems to happen!

But with winpty I call php | grep and nothing happens ;)

[dscho]

They call php -a as you suggested, and nothing seems to happen!

But with winpty I call php | grep and nothing happens ;)

If you seriously suggest I should break other people's setups to unbreak yours, this conversation is pretty much over ;-)

[maxime-pasquier]

Not at all! Please read carefully my last comment: I explain two things: first, I have not found reported issues for PHP and second, the current setup do break PHP! Not just my little setup ;)

So we have:

• without winpty: setup KO for php -a
• with winpty: setup KO for php

We must find a fix to all setups!

[maxime-pasquier]

Hi @dscho,

I have done some research on the PHP Interactive shell:
http://php.net/manual/en/features.commandline.interactive.php:

As of PHP 5.1.0, the CLI SAPI provides an interactive shell using the -a option if PHP is compiled with the --with-readline option.

If you type 'php -a' and get a response of 'Interactive Shell' followed by a 'php>' prompt, you have interactive shell available (PHP was compiled with readline support). If instead you get a response of 'Interactive mode enabled', you DO NOT have interactive shell available and this article does not apply to you.

I try and I have got:

$ winpty php -a
Interactive mode enabled

So I try to install readline, http://php.net/manual/en/intro.readline.php:

Note: This extension is not available on Windows platforms.

And now I am lost: how winpty could be useful on Git for Windows whereas PHP Interactive shell is not available on Windows?

[maxime-pasquier]

No more comments?

[dscho]

I do not recall where I read a comment of a PHP user who did have an interactive console, but I am pretty certain that we have at least one user who installed PHP using some integrated installer and expects to be able to call that from a Git Bash.

[maxime-pasquier]

OK then.

I close this issue, but if somebody has the same issue a solution is provided on the 2nd comment

[galopin]

@dscho @Kmelia Just came across this. It is a real conundrum. It took me several hours to find out how to bypass the winpty thingy…

Actually the solution is pretty simple:

$ 'php' --ini | cat
Configuration File (php.ini) Path: C:\WINDOWS
Loaded Configuration File:         C:\php\5445\php.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

$ 'php' -i | grep "PHP Version"
PHP Version => 5.4.45
PHP Version => 5.4.45

Or much shorter?

$ \php --ini | cat
Configuration File (php.ini) Path: C:\WINDOWS
Loaded Configuration File:         C:\php\5445\php.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

$ \php -i | grep "PHP Version"
PHP Version => 5.4.45
PHP Version => 5.4.45

Or more verbose?

$ command php --ini | cat
Configuration File (php.ini) Path: C:\WINDOWS
Loaded Configuration File:         C:\php\5445\php.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

$ command php -i | grep "PHP Version"
PHP Version => 5.4.45
PHP Version => 5.4.45

🍌 It's quite nifty, isn't it? 🍌

[dscho]

Or php.exe.

[galopin]

Indeed. But php.exe is not portable while \php or 'php' are guaranteed to work. Whether you author a makefile or a Bash script, it will work the same across all POSIX-compliant operating systems…

[dscho]

@galopin true. You could also work with the winpty project to try to make winpty <command> | <other-command> work as expected.