Pipe detection still broken

[joehoyle]

Somehow even though I thought I had fixed pipe / tty detection about 3 times, it still seems to be broken. Most recently in #157.

Basically, I can not get the output TTY detection to work. In a plain PHP script:

// test.php
var_dump( posix_isatty( STDOUT ) );

Running php -f test.php will output bool(true), whereas php -f test.php | grep bool will output bool(false). This is expected, as in the first case, STDOUT is a TTY, and in the second case STDOUT is being piped to grep.

For some reason, when used via composer server cli, no matter what I check, posix_isatty( STDOUT ) is always false.

In Composer commands (Symfony Console), there is a way to detect the TTY support (well, color support), like in https://github.com/symfony/symfony/blob/2.6/src/Symfony/Component/Console/Output/StreamOutput.php#L101. In local-server if I even try to do posix_isatty( $output->getStream() ) I also get FALSE. So, the Console output stream is not a TTY, neither is STDOUT.

I'm not sure if this is just my setup, but either way, it's breaking the TTY detection, which means things like composer server cli post list will not show table columns / dividers etc.

We could disable the TTY detection for STDOUT, and only use the STDIN detection (which works fine). This would mean piping data in to CLI commands should be fine, and also tables and color formatting should work fine. However, it means doing something like composer server cli -- post list --fields=ID | xargs -n 1.... will not work as expected, as xargs will be receiving formatted output.

[roborourke]

We're going to all this effort to support using the composer prefixed commands. We might be able to try out some alternative approaches to this problem using WP CLI remote execution.

WP CLI already has an SSH protocol handler for docker-compose eg in the vendor/altis/local-server/docker directory the following works:

COMPOSE_PROJECT_NAME=altis-dev wp --ssh=docker-compose:php post list --url=altis-dev.altis.dev --fields=ID --format=ids | xargs -n 1

If WP CLI (at least as much of it as is needed to run commands remotely) is included as a depedency of local server we might be able to use composer exec wp instead, by providing a generated default .wp-cli.yml.

[joehoyle]

I think that has too many weaknesses to pursue:

• wp-cli needs to be installed on the host
• --url and other automatable / known values need to be passed manually
• We lose the ability to do any wp wrapping. If we had a composer command that would make use of your above command, we'd now just be at the same point (needing to forward things like if a TTY is present)

[roborourke]

That's not strictly true if we generate a .wp-cli.yml, much of that can be configured. Agree though, needing to install WP CLI as a dep isn't ideal. Just a thought if it's a solved problem in WP CLI already.