You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Compose: Undocumented flag --interactive for docker compose exec #23352
My issue is about the documentation content or website
Type of issue
Information is incorrect
Description
When responding to a contribution, I noticed that the docs for docker compose exec have no -i / --interactive flag (docker exec, docker run, docker compose run all do). This was pointed out back in mid 2023 with a response that it was intentional.
While it doesn't make sense to invoke --interactive with Docker Compose given it's an implicit default, similar to how --tty has been replaced with --no-TTY (this really should accept all lowercase btw), the interactive flag does remain supported for legacy reasons (as noted at earlier linked ref).
Actual valid use-case however has been shown here where I advised a contributor about this hidden flag so that they could ensure a command was run non-interactively within a running container.
Not being able to do this would prevent the bash read -p command from working properly in a non-interactive context.
Document -i / --interactive is actually supported with a default of true and that it is also enabled by compose by default (similar to the equivalent docs of the --no-TTY option).
similar to how --tty has been replaced with --no-TTY
this hasn't been replaced. There's been a distinct design decision in compose vs docker/cli as exec has been introduced in compose (2016). Nowadays we would require better alignment with the CLI for consistency.
Actually, we introduced--tty later in compose to offer ability for user to select same flags for docker exec and docker compose exec, while it is a no-op for compose as a TTY is allocated by default.
Yeah I just realized afterwards that --tty=false also works despite lack of documented option. That helps for consistency when documenting the caveat to users of an image when calling the command and expecting non-interactive usage 👍
which would be a no-op because the defaults between compose and docker are reversed; I think we kept them hidden because the -T flag (disable TTY) already existed, and having both visible would probably be more confusing.
Activity
ndeloof commentedon Sep 4, 2025
this hasn't been replaced. There's been a distinct design decision in compose vs docker/cli as
exechas been introduced in compose (2016). Nowadays we would require better alignment with the CLI for consistency.Actually, we introduced
--ttylater in compose to offer ability for user to select same flags fordocker execanddocker compose exec, while it is a no-op for compose as a TTY is allocated by default.polarathene commentedon Sep 4, 2025
Yeah I just realized afterwards that
--tty=falsealso works despite lack of documented option. That helps for consistency when documenting the caveat to users of an image when calling the command and expecting non-interactive usage 👍thaJeztah commentedon Sep 4, 2025
Ah, yes, these were added so that users familiar with
docker exec -it ...would be able to dodocker compose exec -it,;-iand-tflags ondocker compose runandexeccompose#9207which would be a no-op because the defaults between compose and docker are reversed; I think we kept them hidden because the
-Tflag (disable TTY) already existed, and having both visible would probably be more confusing.thaJeztah commentedon Sep 4, 2025
That can probably be fixed with a NormalizeFunc; https://pkg.go.dev/github.com/spf13/pflag#FlagSet.SetNormalizeFunc
https://github.com/spf13/pflag/blob/0491e5702ad2bb108bc519a5221bcc0f52aa9564/README.md#mutating-or-normalizing-flag-names