0

When a background job in bash completes, it will notify the terminal.

$ sleep 3 &
[1] 17527
$ 
[1]+  Done                    sleep 3
  • Is the notification based on some callback event-handling?

  • does the background job notify the terminal when it completes, by sending some signal to the terminal?

  • Why do I have to hit a return (i.e. run an empty command) to see the notification on the terminal?

1

From the manpage:

The shell learns immediately whenever a job changes state. Normally, bash waits until it is about to print a prompt before reporting changes in a job's status so as to not interrupt any other output. If the -b option to the set builtin command is enabled, bash reports such changes immediately. Any trap on SIGCHLD is executed for each child that exits.

This explains why you need to press Enter before seeing the notification. You can change that by running set -b. It doesn’t have much to do with the terminal, job control is managed by the shell. When a background process terminates, the parent receives a SIGCHLD signal; that’s the notification.

  • Thanks. "When a background process terminates, the parent receives a SIGCHLD signal;" Is the parent the bash process or the terminal process? Is outputting "Done" to stdout the bash's handler when receiving signal SIGCHLD? – Tim Oct 18 '17 at 13:24
  • The parent is the shell. “Done” is output either by the shell’s signal handler, if notifications are asynchronous (set -b), or before printing the prompt. – Stephen Kitt Oct 18 '17 at 13:30
  • Thanks. Does set +b set up the default behavior? – Tim Aug 3 '18 at 13:21
  • I was wondering how to solve this problem unix.stackexchange.com/questions/460135/… adding set -b to the script doesn't seem to work – Tim Aug 3 '18 at 13:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.