Signals cause wait to exit with a status equal to the signal number plus 128. To get the real exit status, loop until $? is less.

#!/bin/bash

trap 'echo trapped' INT TERM
sleep 10 & pid=$!

while wait $pid; test $? -ge 128
do echo 'finished wait'
done

echo bye

Note that test overwrites $? with its own exit status, so if you care about the real exit status from wait, you'll have to create a variable between wait and test.

Can anybody tell why there the difference is?

Ctrl+C gets to sleep as well, while kill <pid> doesn't. In effect the latter way needs sleep to exit by itself before hi! is printed. What you call "1 second delay" is about 1 second at most and about 0.5 on average (it may take longer if the OS is very busy with other tasks).

You can clearly see the difference by using

pv -qL 1 <<< "0123456789"

instead of sleep 1.

Note that

kill -- -<pid>    # note the minus sign before PID

would send the signal to the entire process group, so to sleep (or pv) as well.

Is there a way that always trigger trap command immediately no matter what is going on?

There is this question How to handle signals in bash during synchronous execution?

From one of the answers:

If bash is waiting for a command to complete and receives a signal for which a trap has been set, the trap will not be executed until the command completes. When bash is waiting for an asynchronous command via the wait builtin, the reception of a signal for which a trap has been set will cause the wait builtin to return immediately with an exit status greater than 128, immediately after which the trap is executed.

So, run your external program asynchronously and use wait. Kill it using $!.

In your case this method leads to the following quick and dirty script:

#!/bin/bash

trap 'kill "$!"; echo hi!' SIGINT SIGTERM

echo "pid is $$"
while true; do
    sleep 1 &
    wait
done

Your kill command is backwards.

Like many UNIX commands, options that start with a minus must come first, before other arguments.

If you write

kill -INT 0

it sees the -INT as an option, and sends SIGINT to 0 (0 is a special number meaning all processes in the current process group).

But if you write

kill 0 -INT

it sees the 0, decides there's no more options, so uses SIGTERM by default. And sends that to the current process group, the same as if you did

kill -TERM 0 -INT    

(it would also try sending SIGTERM to -INT, which would cause a syntax error, but it sends SIGTERM to 0 first, and never gets that far.)

So your main script is getting a SIGTERM before it gets to run the wait and echo DONE.

Add

trap 'echo got SIGTERM' TERM

at the top, just after

trap 'killall' INT

and run it again to prove this.

As Stephane Chazelas points out, your backgrounded children (process1, etc.) will ignore SIGINT by default.

In any case, I think sending SIGTERM would make more sense.

Finally, I'm not sure whether kill -process group is guaranteed to go to the children first. Ignoring signals while shutting down might be a good idea.

So try this:

#!/bin/bash
trap 'killall' INT

killall() {
    trap '' INT TERM     # ignore INT and TERM while shutting down
    echo "**** Shutting down... ****"     # added double quotes
    kill -TERM 0         # fixed order, send TERM not INT
    wait
    echo DONE
}

./process1 &
./process2 &
./process3 &

cat # wait forever

#!/bin/bash

trap 'echo "Caught SIGUSR1"' SIGUSR1

echo "Sleeping.  Pid=$$"
while :
do
   sleep 10 &
   wait $!
   echo "Sleep over"
done

This other answer explains why you see trap worked only after done. If you run the subshell in the background and then wait for it, the result will be different:

#!/bin/bash

trap 'echo "trap worked"' INT

(
   trap '' INT
   sleep 5
   echo "done"
) &

wait

If you hit Ctrl+c when the subshell works, it will trigger the trap immediately. It will also make the script go past wait and thus finish. Run wait in a loop if you don't want the script to finish:

until wait; do :; done

This way you will be able to trigger the trap multiple times easily and the script will exit after the subshell exits.

I guess this is not exactly what you mean by "without interrupting the foreground task", since the task (here: sleep) is in the background instead and it has its consequences. When job control is disabled (and it is by default in a script), & redirects stdin to /dev/null or equivalent file. This way what you run in the background cannot steal input. If you want our background subshell to be able to read from the stdin of the whole script then you need to explicitly redirect stdin to stdin (<&0). It looks like a no-op, but with & it actually makes sense, it makes an asynchronous job behave more like a job in the foreground:

(…) <&0 &

Another thing: note wait without arguments waits for all currently active child processes. If your actual script runs more jobs in the background and you want wait not to wait for some of them, the easiest way may be to disown.

Example code:

#!/bin/bash

trap 'echo "trap worked"' INT

(
   trap '' INT
   sleep 10
   echo "(not waited for) done"
) &
disown "$!"

(
   trap '' INT
   cat
   echo "(waited for) done"
) <&0 &

until wait; do :; done

Notes:

• cat and sleep are both immune to Ctrl+c.
• You can strike Ctrl+c and trigger the trap multiple times.
• At the same time you can write lines to cat and it will work, i.e. it will print upon Enter (but if you Ctrl+c in the middle of a line then what you typed so far (i.e. what hasn't been delivered to cat yet) will be discarded and never delivered to cat because this is how the line discipline works).
• Exit cat with Ctrl+d before sleep 10 finishes and you will see the script does not wait for the disowned job.

Side note: while playing with SIGINT and bash, it's good to know bash implements a "wait and cooperative exit" approach at handling SIGINT/SIGQUIT delivery. See this link and this article.

No.

wait is exclusively used in a parent process to wait for the termination of a child process (and to access its exit status).

Furthermore, no process may trap the KILL signal (the original question used KILL as example).

Also, to "wait for a signal" is an unusual thing to want to do, as signals are asynchronous events, meaning you don't wait for them, but instead you install a signal handler (using trap in the shell) that would handle the signal whenever it arrives. A signal could be arriving at any time during the script's execution, and the signal handler would be executed when that happens (the normal program flow would temporarily pause while the signal is being handled).

You could, obviously, do something like

trap 'quit=1' USR1

quit=0
while [ "$quit" -ne 1 ]; do
    printf 'Do "kill -USR1 %d" to exit this loop after the sleep\n' "$$"
    sleep 1
done

echo The USR1 signal has now been caught and handled

to do a sort of a "waiting for signal to arrive" loop.

Here, the "trap" would "catch" the USR1 signal, the "handler" would set quit to 1, and control would be returned to the code, which would exit the loop.

The wait is interrupted by the incoming signal and does not get restarted. You should be able to just add another wait call to force it to finish waiting. There is probably a better way to do that though.

echo "P1: waiting for p2 ($child)"
wait $child
wait $child

echo "P1: Finished waiting for p2, exiting p1"