Introduction

The -i and -t options control how docker exec connects your terminal to a process running inside a container. -i keeps standard input open, while -t allocates a pseudo-terminal, which makes interactive shells feel like a normal terminal session.

What docker exec Does

docker exec starts a new process in an already running container.

Example:

docker exec my-container ls /app

That runs ls /app inside my-container and prints the output.

When you want a shell or another interactive program, terminal behavior starts to matter. That is where -i and -t come in.

The -i Option Keeps STDIN Open

-i means interactive input should remain attached.

Example:

docker exec -i my-container cat

Now cat can receive input from your terminal. Without -i, standard input may be closed, so programs that expect input can behave unexpectedly or exit immediately.

Use -i when:

• the command needs input
• you want to pipe data into the container process
• you are interacting with a shell or REPL

A useful non-terminal example:

echo "hello" | docker exec -i my-container cat

Here -i is necessary because the process inside the container must keep reading standard input.

The -t Option Allocates A Pseudo-TTY

-t creates a pseudo-terminal inside the container session.

Example:

docker exec -t my-container bash

A TTY affects things such as:

• line editing
• colorized output
• cursor movement
• interactive shell behavior

Many command-line tools detect whether they are attached to a terminal. Without -t, some tools switch to plain non-interactive behavior.

That is why bash, sh, and similar shells usually feel more natural with -t.

Why -it Is So Common

You often see the two options together:

docker exec -it my-container bash

This means:

• keep stdin open
• allocate a terminal

That combination is what most people want for an interactive shell session inside a container.

It lets you type commands, see prompts, use arrow keys, and generally behave as if you had logged into a normal machine.

When You Need Only One Of Them

Not every command needs both flags.

Use only -i when you are feeding input but do not need a terminal:

echo "select 1;" | docker exec -i my-db mysql -uroot -psecret

Use only -t less often, but it can make sense when a program benefits from terminal formatting and no stdin stream is required.

For many automated scripts, using neither flag is the right choice because the command is non-interactive and should produce plain output.

TTY Changes Output Behavior

A pseudo-terminal can change how programs print output. Some tools add colors, progress bars, or carriage-return updates only when a TTY is present.

That means -t is great for humans but sometimes bad for automation. If a script needs clean parseable output, skipping -t may be the better choice.

This is one reason CI scripts often avoid -it unless they really need an interactive shell.

Common Pitfalls

The biggest mistake is using -t in a non-interactive pipeline and then wondering why the output contains unexpected terminal formatting or why the environment complains that no TTY is available.

Another mistake is forgetting -i when piping input into a process. Without it, the program inside the container may see closed stdin.

People also overuse -it because it is common in examples. For simple non-interactive commands such as docker exec my-container ls, neither option is necessary.

Finally, if a command behaves differently with and without -t, remember that many tools detect terminal presence and adjust their behavior automatically.

Summary

• '-i keeps standard input open for the process inside the container.'
• '-t allocates a pseudo-terminal for terminal-style interaction.'
• '-it is the usual combination for opening an interactive shell inside a container.'
• Use only -i when piping input, and avoid -t in scripts when plain output is preferable.
• Choose the flags based on whether the process needs input, terminal behavior, or both.