What happens when I press Ctrl+C while a command is running?

In Bash, Ctrl+C usually generates SIGINT. In the documented terminal and job-control setup, the terminal may send that keyboard-generated signal to processes in the foreground process group [S1]. In everyday terms, it is a request for the running foreground work to stop or pay attention—not a universal off switch.

What happens next depends on the command. It might exit, handle the signal in its own way, or keep running. Bash’s documented behavior is specific to Bash and the described setup; it does not establish that Ctrl+C always stops a command or leaves all work unchanged [S1].

If you do not know what the command is doing, pause to read the command and any visible output before deciding. An interruption may occur while the program is doing work, so do not assume it safely undid anything.

Look for a change in the terminal rather than relying on one sign. A shell prompt often appears after the foreground command finishes; while a command is active, you may instead see continuing output, a progress display, or a cursor waiting without the usual prompt. These are clues, not a guarantee: prompts and command output vary.

For example, suppose you run a hypothetical command that prints Working… repeatedly. If that output continues and your usual prompt has not returned, the command may still be active. If the prompt returns, the shell is ready for another command. If the screen is unclear, avoid typing an unrelated command into it; first identify what is displayed and whether the prompt has returned.

A terminal can also appear idle while a program waits for input or does work without printing. So silence alone does not prove that a command has finished. If you are unsure, note the exact command and visible state before taking another action.

Not automatically. A program may handle SIGINT rather than terminate, and the way the signal reaches foreground work depends on the shell and job-control circumstances [S1]. Pressing the key again is not a reliable way to discover what the program is doing or whether its work is safe to interrupt.

First, read any response that appeared after the keypress. The program might be asking a question, reporting that it is stopping, or continuing its task. Check whether the prompt has returned. If it has not and the command’s purpose or possible effects are unclear, stop guessing: record the command and what the terminal shows, then consult the program’s documentation or someone responsible for that task.

For a low-stakes, understood command, you can decide based on its documented behavior. For an operation that could change or remove data, do not infer that interruption reverses earlier work. The source explains signal behavior; it does not establish what a particular application has already done or will do.

Use this before pressing Ctrl+C:

1. Read the full command, not just its last word. If you cannot explain what it is doing, do not treat interruption as a safe experiment.
2. Check the visible output and whether the usual shell prompt has returned. Continued output, a progress display, or no prompt can suggest the foreground command is still active, but none is conclusive by itself.
3. Consider whether the command might have changed files, sent a request, or performed another action already. Ctrl+C is not proof that earlier work was undone.
4. If you choose to press Ctrl+C, watch for the program’s response and check whether the prompt returns. In Bash, the key usually generates SIGINT, but a program may handle it instead of exiting [S1].
5. If the result is unclear, record the command and terminal output and consult the relevant documentation or task owner rather than repeatedly guessing.

That checklist helps you make a deliberate choice; it cannot predict every program’s response. The cited Bash documentation does not establish the behavior of every shell, terminal, or application.