33

Ctrl+Z stops the job whereas Ctrl+C kills the job.

Why is that? Wouldn't the other way make more sense?

z@z-lap:~$ sleep 100&
[1] 4458
z@z-lap:~$ sleep 200&
[2] 4459
z@z-lap:~$ jobs
[1]-  Running                 sleep 100 &
[2]+  Running                 sleep 200 &
z@z-lap:~$ fg %1
sleep 100
^Z
[1]+  Stopped                 sleep 100
z@z-lap:~$ jobs
[1]+  Stopped                 sleep 100
[2]-  Running                 sleep 200 &
z@z-lap:~$ fg %1
sleep 100
^C
z@z-lap:~$ jobs
[2]+  Running                 sleep 200 &
Anderson
  • 139
neo0
  • 755
  • 2
  • 7
  • 7

1 Answers1

70

I think you may be confused about the job control notation. Notably "Stopped" means that a job is still alive but that its ability to process anything has been held (it is not given any time on the CPU to process anything). This is effectively a "Pause" or "Suspended" state, although that is not the correct technical term.

  • CtrlC does not "stop" a job, it cancels or kills it. Technically it causes an interrupt signal to be sent to the program telling it to abort what it is doing and exit immediately. Some programs will hear this signal and do some emergency clean up work on themselves before exiting. Others will not respond to the signal and are subsequently just aborted.

  • CtrlZ, on the other hand, "stops" a job. Again this is done with a signal, but this time it is a 'stop' instead of an 'interrupt' signal. This effectively puts it on hold and returns control to the shell, but does not actually kill the job. If you would like such a job to keep running, you can then issue a bg command to send the last stopped job to the background. It will then continue running as a background job as if you had run it with & in the first place. You may also use fg to resume the last stopped job in the foreground (allowing it to continue where it left off, and allowing you to interact with it again).

dr_
  • 29,602
Caleb
  • 70,105
  • I still think that Ctrl+Z will send SIGKILL and Ctrl+C sends SIGINIT. So the Ctrl+Z would also kills the job. But from my example Ctrl+Z only Stops the job like you said. So it make me a little confused. – neo0 Jun 08 '14 at 07:58
  • 11
    @neo0 - maybe you're used to some weird custom setup? You can configure that stuff - though you probably shouldn't in case you have an application that relies on those maps. But the default configuration is CTRL+C=SIGINT and CTRL+Z=SIGTSTP. – mikeserv Jun 08 '14 at 08:17
  • 3
    Caleb is right (+1). The ctrl-Z stops the program, which you should regard as "freezing" it, but that program still is in memory, it's files opened, etc. It is not killed/terminated. – Olivier Dulac Jun 08 '14 at 08:23
  • "Suspend" might be clearer than "stop". – Russell Borogove Jun 08 '14 at 16:43
  • @Russell If you were architecting UNIX from scratch today maybe you would us that but the signal is a stop signal and the guy's shell is telling him the job is stopped--hence my choice to use that term but explain what it means in context. – Caleb Jun 08 '14 at 18:45
  • So you need at least 2 commands (ctrl+Z and bg) to make a process run in the background after starting it in the foreground? – jiggunjer Aug 25 '16 at 11:24
  • 1
    @jiggunjer That's about the shape of things. This answer gives some background on why two steps are required and this one introduces some functions to make those steps more painless. – Caleb Aug 25 '16 at 14:07
  • I suppose a screen session might count as a 1 command backgrounder. – jiggunjer Aug 25 '16 at 16:43
  • @Caleb +1 for mention of the bg command. – Vijay Varadan May 08 '17 at 00:10