Do not try to guess when to allocate a TTY and keep it as default

[ulyssessouza]

What I did
Do not try to guess when to allocate a TTY and keep it as default

Related issue
Resolves #8908

[ndeloof]

I can't find a better fix for this, but still sad we have to give up with tty detection, and wonder this will trigger more issues from users who expect compose to automatically adjust to environment :-/

[ulyssessouza]

@ndeloof Yep. I also tried to save the automatic behaviour, but without success...
But at least the possible issues will have just a "-T" as "fix"

[thaJeztah]

SGTM

just to double-check; this brings it to the same behaviour / defaults as compose v1, correct?

[rfay]

Since panic is a result of this I don't think it's probably satisfactory, see https://stackoverflow.com/questions/70855915/fix-panic-provided-file-is-not-a-console-from-docker-compose-in-github-action

[ndeloof]

I don't like this either. I expect we get rid of this as we share more code with docker/cli, especially relying on the exact same RunExec function

[rfay]

Right... but not preventing a panic? that doesn't seem like the right thing...

[ndeloof]

We can burn some cycles trying to find a better way to manage this and avoid a panic, which is obviously the worst possible user experience to offer :'(
but with #9198 and docker/cli#3436 we are close to just drop all the custom exec code implemented by docker/compose to adopt the battle-tested RunExec code used by the docker CLI for years.

[rfay]

Sounds good. I had actually planned long ago and half-implemented a switch to using docker's exec for ddev exec instead of using docker-compose exec but didn't actually pull the trigger, just worried about unexpected results.

[rostislav-simonik-plc]

Hello, i just tested with version 2.6.1 of docker compose and still having the issue. Once i remove exec with tee it starts working.