In an interactive Bash session with job control, Ctrl+Z usually suspends the foreground job. The shell prompt can return even though the work has not completed or exited. Starting the original command again may create a second attempt while the first remains stopped.

Inspect the original session

Keep the terminal tab open and run jobs in that same shell. Bash lists its jobs with bracketed numbers and states such as Stopped or Running. Compare the command text with the operation you were performing before choosing a job.

Job numbers belong to that shell's job table. A number from another terminal, an old screenshot or a previous session is not a reliable reference. If there are several jobs, record which one corresponds to the interrupted task rather than relying on whichever job Bash currently considers the default.

Before resuming, consider the effect of the pause. A transfer or session may have timed out, and another person may have changed the destination. Check the application's documented recovery requirements if continuing could repeat a transaction or conflict with new work.

Bring the intended job back

Use fg followed by the verified job specification, such as fg %1 when the relevant entry is actually job 1. This resumes that existing job in the foreground. Read its next output and respond to any legitimate prompt instead of assuming the pause was invisible to the application.

The bg command has a different purpose: it continues a job in the background. A program that needs terminal input may stop again there, so moving an interactive task to the background is not a universal solution.

Wait for the application's normal completion and verify the resulting file or other intended outcome. If you decide to cancel, use its documented exit procedure and inspect any partial work. Bash can warn about stopped jobs when you exit; do not dismiss that warning by immediately exiting again without deciding what should happen to the remaining work.

Sources: GNU documentation.