# Sending keys

Source: https://libtmux.org/en/lua/latest/guides/sending-keys/

> Literal text versus tmux key names, whether Enter is pressed for you, and why a command can outrun the shell about to run it.

Send literal text to type characters into a pane, or send tmux key names such as
`C-c`, `Enter`, and `Up` to press those keys. Check the method's literal-text
and Enter defaults: typing the word `Enter` and pressing Enter are different
operations.

## Literal text, key names, and whether Enter follows

These examples show each port's text, named-key, and Enter behavior. [Attach and
send keys](/examples/attach-and-send-keys/) provides the full source examples
and validation details.

Check each method's input contract before sending text that could be a key name.
Some ports separate text and key-name methods; others use a literal-text flag.
[Concepts](/concepts/) introduces the shared tmux model.

## The race you can't see from the call site

Completing `send-keys` means tmux accepted the input. The shell may still be
starting, and the command may still be running. The port examples provide
different ways to wait:

- **Rust** uses a `retry_until` loop in the README's query example to wait for
  the shell.
- **Go** provides `tmuxtest.WaitForShellReady` for tests that need a ready
  shell.
- **.NET** demonstrates waiting for command output in the README's "Running
  something, and reading it back" section.

Wait for shell readiness before sending input when startup matters. Then wait
for the command's expected output or a completion signal before reading its
result. The next guide covers those waiting APIs.

## Where to go next

- [Capturing output](../capturing-output/): reading back what you just
  sent, and waiting for it correctly instead of guessing a delay.
- [Attach and send keys](/examples/attach-and-send-keys/): the full
  sourced round trip this guide picks apart piece by piece.